Kemuri Water Company (KWC) | Hackers change chemical settings at water treatment plant

The unnamed water district had asked Verizon to assess its networks for indications of a security breach. It said there was no evidence of unauthorized access, and the assessment was a proactive measure as part of ongoing efforts to keep its systems and networks healthy.

Verizon examined the company’s IT systems, which supported end users and corporate functions, as well as Operational Technology (OT) systems, which were behind the distribution, control and metering of the regional water supply.

The assessment found several high-risk vulnerabilities on the Internet-facing perimeter and said that the OT end relied heavily on antiquated computer systems running operating systems from 10 or more years ago.

Many critical IT and OT functions ran on a single IBM AS/400 system which the company described as its SCADA (Supervisory Control and Data Acquisition) platform. This system ran the water district’s valve and flow control application that was responsible for manipulating hundreds of programmable logic controllers (PLCs), and housed customer and billing information, as well as the company’s financials.

Interviews with the IT network team uncovered concerns surrounding recent suspicious cyber activity and it emerged that an unexplained pattern of valve and duct movements had occurred over the previous 60 days. These movements consisted of manipulating the PLCs that managed the amount of chemicals used to treat the water to make it safe to drink, as well as affecting the water flow rate, causing disruptions with water distribution, Verizon reported.

An analysis of the company’s internet traffic showed that some IP addresses previously linked to hacktivist attacks had connected to its online payment application.

Verizon said that it “found a high probability that any unauthorized access on the payment application would also expose sensitive information housed on the AS/400 system.” The investigation later showed that the hackers had exploited an easily identified vulnerability in the payment application, leading to the compromise of customer data. No evidence of fraudulent activity on the stolen accounts could be confirmed.

However, customer information was not the full extent of the breach. The investigation revealed that, using the same credentials found on the payment app webserver, the hackers were able to interface with the water district’s valve and flow control application, also running on the AS/400 system.

During these connections, they managed to manipulate the system to alter the amount of chemicals that went into the water supply and thus interfere with water treatment and production so that the recovery time to replenish water supplies increased. Thanks to alerts, the company was able to quickly identify and reverse the chemical and flow changes, largely minimizing the impact on customers. No clear motive for the attack was found, Verizon noted.

The company has since taken remediation measures to protect its systems.

In its concluding remarks on the incident, Verizon said: “Many issues like outdated systems and missing patches contributed to the data breach — the lack of isolation of critical assets, weak authentication mechanisms and unsafe practices of protecting passwords also enabled the threat actors to gain far more access than should have been possible.”

Acknowledging that the company’s alert functionality played a key role in detecting the chemical and flow changes, Verizon said that implementation of a “layered defense-in-depth strategy” could have detected the attack earlier, limiting its success or preventing it altogether.

 

About the attack [UPDATED]

A “hacktivist” group with ties to Syria compromised Kemuri Water Company’s computers after exploiting unpatched web vulnerabilities in its internet-facing customer payment portal, it is reported.

The hack – which involved SQL injection and phishing – exposed KWC’s ageing AS/400-based operational control system because login credentials for the AS/400 were stored on the front-end web server. This system, which was connected to the internet, managed programmable logic controllers (PLCs) that regulated valves and ducts that controlled the flow of water and chemicals used to treat it through the system. Many critical IT and operational technology functions ran on a single AS400 system, a team of computer forensic experts from Verizon subsequently concluded.

Our endpoint forensic analysis revealed a linkage with the recent pattern of unauthorised crossover. Using the same credentials found on the payment app webserver, the threat actors were able to interface with the water district’s valve and flow control application, also running on the AS400 system. We also discovered four separate connections over a 60-day period, leading right up to our assessment.During these connections, the threat actors modified application settings with little apparent knowledge of how the flow control system worked. In at least two instances, they managed to manipulate the system to alter the amount of chemicals that went into the water supply and thus handicap water treatment and production capabilities so that the recovery time to replenish water supplies increased. Fortunately, based on alert functionality, KWC was able to quickly identify and reverse the chemical and flow changes, largely minimising the impact on customers. No clear motive for the attack was found.

Verizon’s RISK Team uncovered evidence that the hacktivists had manipulated the valves controlling the flow of chemicals twice – though fortunately to no particular effect. It seems the activists lacked either the knowledge of SCADA systems or the intent to do any harm.

The same hack also resulted in the exposure of personal information of the utility’s 2.5 million customers. There’s no evidence that this has been monetized or used to commit fraud.

Nonetheless, the whole incident highlights the weaknesses in securing critical infrastructure systems, which often rely on ageing or hopelessly insecure setups.

 

KWC

 

More Information

Monzy Merza, Splunk’s director of cyber research and chief security evangelist, commented: “Dedicated and opportunistic attackers will continue to exploit low-hanging fruit present in outdated or unpatched systems. We continue to see infrastructure systems being targeted because they are generally under-resourced or believed to be out of band or not connected to the internet.”

“Beyond the clear need to invest in intrusion detection, prevention, patch management and analytics-driven security measures, this breach underscores the importance of actionable intelligence. Reports like Verizon’s are important sources of insight. Organisations must leverage this information to collectively raise the bar in security to better detect, prevent and respond to advanced attacks. Working collectively is our best route to getting ahead of attackers,” he added.

Reports that hackers have breached water treatment plants are rare but not unprecedented. For example, computer screenshots posted online back in November 2011 purported to show the user interface used to monitor and control equipment at the Water and Sewer Department for the City of South Houston, Texas by hackers who claimed to have pwned its systems. The claim followed attempts by the US Department of Homeland Security to dismiss a separate water utility hack claim days earlier.

More recently hackers caused “serious damage” after breaching a German steel mill and wrecking one of its blast furnaces, according to a German government agency. Hackers got into production systems after tricking victims with spear phishing emails, said the agency.

Spear phishing also seems to have played a role in attacks lining the BlackEnergy malware against power utilities in the Ukraine and other targets last December. The malware was used to steal user credentials as part of a complex attack that resulted in power outages that ultimately left more than 200,000 people temporarily without power on 23 December.

 

Credit:  watertechonline, theregister

[CRITICAL] Nissan Leaf Can Be Hacked Via Web Browser From Anywhere In The World

How The Nissan Leaf Can Be Hacked Via Web Browser From Anywhere In The World

What if a car could be controlled from a computer halfway around the world? Computer security researcher and hacker Troy Hunt has managed to do just that, via a web browser and an Internet connection, with an unmodified Nissan Leaf in another country. While so far the control was limited to the HVAC system, it’s a revealing demonstration of what’s possible.

Hunt writes that his experiment started when an attendee at a developer security conference where Hunt was presenting realized that his car, a Nissan Leaf, could be accessed via the internet using Nissan’s phone app. Using the same methods as the app itself, any other Nissan Leaf could be controlled as well, from pretty much anywhere.

Hunt made contact with another security researcher and Leaf-owner, Scott Helme. Helme is based in the UK, and Hunt is based in Australia, so they arranged an experiment that would involve Hunt controlling Helme’s LEAF from halfway across the world. Here’s the video they produced of that experiment:

As you can see, Hunt was able to access the Leaf in the UK, which wasn’t even on, and gather extensive data from the car’s computer about recent trips, distances of those trips (recorded, oddly, in yards) power usage information, charge state, and so on. He was also able to access the HVAC system to turn on the heater or A/C, and to turn on the heated seats.

It makes sense these functions would be the most readily available, because those are essentially the set of things possible via Nissan’s Leaf mobile app, which people use to heat up or cool their cars before they get to them, remotely check on the state of charge, and so on.

This app is the key to how the Leaf can be accessed via the web, since that’s exactly what the app does. The original (and anonymous) researcher found that by making his computer a proxy between the app and the internet, the requests made from the app to Nissan’s servers can be seen. Here’s what a request looks like:

GET https://[redacted].com/orchestration_1111/gdc/BatteryStatusRecordsRequest.php?RegionCode=NE&lg=no-NO&DCMID=&VIN=SJNFAAZE0U60XXXXX&tz=Europe/Paris&TimeFrom=2014-09-27T09:15:21

If you look in that code, you can see that part of the request includes a tag for VIN, which is the Vehicle Identification Number (obfuscated here) of the car. Changing this VIN is really all you need to do to access any particular Leaf. Remember, VIN are visible through the windshield of every car, by law.

Hunt describes the process on his site, and notes some alarming details:

This is pretty self-explanatory if you read through the response; we’re seeing the battery status of his LEAF. But what got Jan’s attention is not that he could get the vehicle’s present status, but rather that the request his phone had issued didn’t appear to contain any identity data about his authenticated session.

In other words, he was accessing the API anonymously. It’s a GET request so there was nothing passed in the body nor was there anything like a bearer token in the request header. In fact, the only thing identifying his vehicle was the VIN which I’ve partially obfuscated in the URL above.

So, there’s no real security here to prevent accessing data on a LEAF, nor any attempt to verify the identity on either end of the connection.

How The Nissan Leaf Can Be Hacked Via Web Browser From Anywhere In The World

And it gets worse. Here, quoting from Hunt’s site, he’s using the name “Jan” to refer to the anonymous Leaf-owning hacker who discovered this:

But then he tried turning it on and observed this request:

GET https://[redacted].com/orchestration_1111/gdc/ACRemoteRequest.php?RegionCode=NE&lg=no-NO&DCMID=&VIN=SJNFAAZE0U60XXXXX&tz=Europe/Paris

That request returned this response:

{

status:200

message: “success”,

userId: “******”,

vin: “SJNFAAZE0U60****”,

resultKey: “***************************”

}

This time, personal information about Jan was returned, namely his user ID which was a variation of his actual name. The VIN passed in the request also came back in the response and a result key was returned.

He then turned the climate control off and watched as the app issued this request:

GET https://[redacted].com/orchestration_1111/gdc/ACRemoteOffRequest.php?RegionCode=NE&lg=no-NO&DCMID=&VIN=SJNFAAZE0U60XXXXX&tz=Europe/Paris

All of these requests were made without an auth token of any kind; they were issued anonymously. Jan checked them by loading them up in Chrome as well and sure enough, the response was returned just fine. By now, it was pretty clear the API had absolutely zero access controls but the potential for invoking it under the identity of other vehicles wasn’t yet clear.

Even if you don’t understand the code, here’s what all that means: we have the ability to get personal data and control functions of the car from pretty much anywhere with a web connection, as long as you know the target car’s VIN.

Hunt proved this was possible after some work, using a tool to generate Leaf VINs (only the last 5 or 6 digits are actually different) and sending a request for battery status to those VINs. Soon, they got the proper response back. Hunt explains the significance:

This wasn’t Jan’s car; it was someone else’s LEAF. Our suspicion that the VIN was the only identifier required was confirmed and it became clear that there was a complete lack of auth on the service.

Of course it’s not just an issue related to retrieving vehicle status, remember the other APIs that can turn the climate control on or off. Anyone could potentially enumerate VINs and control the physical function of any vehicles that responded. That’s was a very serious issue. I reported it to Nissan the day after we discovered this (I wanted Jan to provide me with more information first), yet as of today – 32 days later – the issue remains unresolved. You can read the disclosure timeline further down but certainly there were many messages and a phone call over a period of more than four weeks and it’s only now that I’m disclosing publicly…

How The Nissan Leaf Can Be Hacked Via Web Browser From Anywhere In The World

(Now, just to be clear, this is not a how-to guide to mess with someone’s Leaf. You’ll note that the crucial server address has been redacted, so you can’t just type in those little segments of code and expect things to work.)

While at the moment, you can only control some HVAC functions and get access to the car’s charge state and driving history, that’s actually more worrying than you may initially think.

Not only is there the huge privacy issue of having your comings-and-goings logged and available, but if someone wanted to, they could crank the AC and drain the battery of a Leaf without too much trouble, stranding the owner somewhere.

There’s no provision for remote starting or unlocking at this point, but the Leaf is a fully drive-by-wire vehicle. It’s no coincidence that every fully autonomous car I’ve been in that’s made by Nissan has been on the LEAF platform; all of its major controls can be accessed electronically. For example, the steering wheel can be controlled (and was controlled, as I saw when visiting Nissan’s test facility) by the motors used for power steering assist, and it’s throttle (well, for electrons)-by-wire, and so on.

So, at this moment I don’t think anyone’s Leaf is in any danger other than having a drained battery and an interior like a refrigerator, but that’s not to say nothing else will be figured out. This is a huge security breach that Nissan needs to address as soon as possible. (I reached out to Nissan for comment on this story and will update as soon as I get one.)

So far, Nissan has not fixed this after at least 32 days, Hunt said. Here’s how he summarized his contact with Nissan:

I made multiple attempts over more than a month to get Nissan to resolve this and it was only after the Canadian email and French forum posts came to light that I eventually advised them I’d be publishing this post. Here’s the timeline (dates are Australian Eastern Standard time):

  • 23 Jan: Full details of the findings sent and acknowledged by Nissan Information Security Threat Intelligence in the U.S.A.
  • 30 Jan: Phone call with Nissan to fully explain how the risk was discovered and the potential ramifications followed up by an email with further details
  • 12 Feb: Sent an email to ask about progress and offer further support to which I was advised “We’re making progress toward a solution”
  • 20 Feb: Sent details as provided by the Canadian owner (including a link to the discussion of the risk in the public forum) and advised I’d be publishing this blog post “later next week”
  • 24 Feb: This blog published, 4 weeks and 4 days after first disclosure

All in all, I sent ten emails (there was some to-and-fro) and had one phone call. This morning I did hear back with a request to wait “a few weeks” before publishing, but given the extensive online discussions in public forums and the more than one-month lead time there’d already been, I advised I’d be publishing later that night and have not heard back since. I also invited Nissan to make any comments they’d like to include in this post when I contacted them on 20 Feb or provide any feedback on why they might not consider this a risk. However, there was nothing to that effect when I heard back from them earlier today, but I’ll gladly add an update later on if they’d like to contribute.

I do want to make it clear though that especially in the earlier discussions, Nissan handled this really well. It was easy to get in touch with the right people quickly and they made the time to talk and understand the issue. They were receptive and whilst I obviously would have liked to see this rectified quickly, compared to most ethical disclosure experiences security researches have, Nissan was exemplary.

It’s great Nissan was “exemplary” but it would have been even better if they’d implemented at least some basic security before making their cars’ data and controls available over the internet.

How The Nissan Leaf Can Be Hacked Via Web Browser From Anywhere In The World

Security via obscurity just isn’t going to cut it anymore, as Troy Hunt has proven through his careful and methodical work. I’m not sure why carmakers don’t seem to be taking this sort of security seriously, but it’s time for them to step up.

After all, doing so will save them from PR headaches like this, and the likely forthcoming stories your aunt will Facebook you about how the terrorists are going to make all the Leafs hunt us down like dogs.

Until they have to recharge, at least.

(Thanks, Matt and Brandon!)

 

 

Credit:  Jason Torchinsky

Pro-Palestinian Hackers Took over Radio Tel Aviv Website

A group of pro-Palestinian hackers took over the official website of Radio Tel Aviv (TLV) on Sunday and left a deface page on the homepage showing anti-Israeli messages.

A group of Palestinian-friendly hackers going with the handle of AnonCoders hacked and defaced the official website of Radio Tel Aviv.

Hackers left a deface page along with messages both in support of Palestine and against Israel and Zionism.

The Israeli newspaper YT News reports that the deface page uploaded by the group remained on the Radio Tel Aviv’s website for more than a day after it was removed by the site’s admin. However, the Radio transmission remained unharmed.

The message on the website described why the site was targeted:

“Because we are the voice of Palestine and we will not remain silent. And our main target is Zionism and Israhell, if you are asking why your website got hacked by us, it’s basically because we want to share our message.”

A full preview of the deface page is available below:

pro-palestinian-hackers-took-over-radio-tel-aviv-website

Link of targeted website along with its zone-h mirror as a proof of hack is available below:

http://102fm.co.il/
http://zone-h.org/mirror/id/24931127?zh=1

This is not the first time when pro-Palestinian hackers took over an Israeli entertainment service provider. In the past, the cyber wing of Hamas hacked the official TV broadcasts of Israeli Channel 2 and Channel 10 for a short period of time.

In 2013, Israel’s major traffic tunnel was hit by a massive cyber-attack, causing huge financial damage.

In March 2014, Al-Qassam hackers from Palestine compromised the IsraelDefense magazine database and its website, to launch SMS attack on Israeli journalists.

 

 

Credit: 

Firefox Under Fire: Anatomy of latest 0-day attack

On the August 6th, the Mozilla Foundation released a security update for the Firefox web browser that fixes the CVE-2015-4495 vulnerability in Firefox’s embedded PDF viewer, PDF.js. This vulnerability allows attackers to bypass the same-origin policy and execute JavaScript remotely that will be interpreted in the local file context. This, in turn, allows attackers to read and write files on local machine as well as upload them to a remote server. The exploit for this vulnerability is being actively used in the wild, so Firefox users are advised to update to the latest version (39.0.3 at the time of writing) immediately.

In this blog we provide an analysis of two versions of the script and share details about the associated attacks against Windows, Linux and OS X systems.

According to ESET’s LiveGrid® telemetry, the server at the IP address 185.86.77.48, which was hosting the malicious script, has been up since July 27, 2015. Also we can find corroboration on one of the compromised forums:

image1

Operatives from the Department on Combating Cybercrime of the Ministry of Internal Affairs of Ukraine, who responded promptly to our notification, have also confirmed that the malicious exfiltration server, hosted in Ukraine, has been online since July 27, 2015.

According to our monitoring of the threat, the server became inactive on August 8, 2015.

 

The script

The script used is not obfuscated and easy to analyze. Nevertheless, the code shows that the attackers had good knowledge of Firefox internals.

The malicious script creates an IFRAME with an empty PDF blob. When Firefox is about to open the PDF blob with the internal PDF viewer (PDF.js), new code is injected into the IFRAME (Figure 2). When this code executes, a new sandboxContext property is created within wrappedJSObject. A JavaScript function is written to the sandboxContext property. This function will later be invoked by subsequent code. Together, these steps lead to the successful bypass of the same-origin policy.

Code that creates sandboxContext property

The exploit is very reliable and works smoothly. However, it may display a warning which can catch the attention of tech-savvy users.

The warning message showed on compromised site

After successful exploitation of the bug, execution passes to the exfiltration part of code. The script supports both the Linux and Windows platforms. On Windows it searches for configuration files belonging to popular FTP clients (such as FileZilla, SmartFTP and others), SVN client, instant messaging clients (Psi+ and Pidgin), and the Amazon S3 client.

The list of collected files on Windows at the first stage of attack

These configuration files may contain saved login and password details.

On the Linux systems, the script sends following files to the remote server:

  • /etc/passwd
  • /etc/hosts
  • /etc/hostname
  • /etc/issue

It also parses the /etc/passwd file in the order to get the home directories (homedir) of users on the system. The script then searches files by mask in the home directories collected, and it avoids searching in the home directories of standard system users (such as daemon, bin, sys, sync and so forth).

The list of collected files on Linux at stage 1 of attack

It collects and uploads such files as:

  • history (bash, MySQL, PostgreSQL)
  • SSH related configuration files and authorization keys
  • Configuration files for remote access software – Remmina
  • FileZilla configuration files
  • PSI+ configuration
  • text files with possible credentials and shell scripts

As is evident here, the purpose of the first version of the malicious script was to gather data used mostly by webmasters and site administrators. This allowed attackers to move on to compromising more websites.

 

The second version

The day after Mozilla released the patch for Firefox the attackers decided to go “all-in”: they registered two new domains and improved their script.

The two new malicious domains were maxcdnn[.]com (93.115.38.136) and acintcdn[.]net (185.86.77.48). The second IP address is the same one as used in the first version. Attackers selected these names because the domains look as if they belong to a content delivery network (CDN).

The improved script on the Windows platform not only collects configuration files for applications; it also collects text files containing almost all combinations of words of possible value to attackers (such as password, accounts, bitcoins, credit cards, exploits, certificates, and so on):

List of files collected on Windows during the second attack stage

The attackers improved the Linux script by adding new files to collect and also developed code that works on the Mac OS X operating system:

List of files collected on Macs during the second stage of an attack

Some Russian-speaking commentators misattributed this code to the Duqu malware, because some variables in the code have the text “dq” in them.

 

A copycat attack

Since the bug is easy to exploit and a working copy of the script is available to cybercriminals, different attackers have started to use it. We have seen that various groups quickly adopted the exploit and started to serve it, mostly on adult sites from google-user-cache[.]com (108.61.205.41)

This malicious script does all the same things as the original script, but it collects different files:

The list of collected files used in copycat attack

 

Conclusion

The recent Firefox attacks are an example of active in-the-wild exploitation of a serious software vulnerability. The exploit shows that the malware-writers had a deep knowledge of Firefox internals. It is also an interesting one, since in most cases, exploits are used as an infection vector for other data-stealing trojans. In this instance, however, that was not necessary, because the malicious script alone was able to steal sensitive files from victims’ systems.

Additionally, the exploit started to be reused by other malware operators shortly after its discovery. This is common practice in the malware world.

ESET detects the malicious scripts as JS/Exploit.CVE-2015-4495. We also urge Firefox users to update their browser to the patched version (39.0.3). The internal Firefox PDF reader can also be disabled by changing the pdfjs.disabled setting to true.

 

Indicators of Compromise

A partial list of compromised servers:

hxxp://www.akipress.org/

hxxp://www.tazabek.kg/

hxxp://www.super.kg/

hxxp://www.rusmmg.ru/

hxxp://forum.cs-cart.com/

hxxp://www.searchengines.ru/

hxxp://forum.nag.ru/

Servers used in attack:

maxcdnn[.]com (93.115.38.136)

acintcdn[.]net (185.86.77.48)

google-user-cache[.]com (108.61.205.41)

Hashes (MD5):

0A19CC67A471A352D76ACDA6327BC179547A7A25

2B1A220D523E46335823E7274093B5D44F262049

19BA06ADF175E2798F17A57FD38A855C83AAE03B

3EC8733AB8EAAEBD01E5379936F7181BCE4886B3

 
 

Credit:  Anton Cherepanov

FBI Links Chinese Government to DDoS Attacks on US Websites

 

The FBI says it has credible evidence to link the Chinese government to attackers who leveraged two Chinese telecom companies and the Baidu search engine to carry out recent distributed denial of service (DDoS) attacks targeting unnamed U.S. websites.

The FBI issued a confidential Flash Alert to U.S. companies alleging that the Chinese government sanctioned activities in which Internet traffic was “manipulated to create cyber attacks directed at U.S.-based websites” using man-in-the-middle (MitM) techniques.

“Analysis by the U.S. government indicated that Internet traffic which originated outside China, was intercepted and modified to make unsuspecting users send repeated requests to U.S.-based websites,” the Flash Alert reportedly said.

“The malicious activity occurred on China’s backbone Internet infrastructure, and temporarily disrupted all operations on the U.S.-based websites.”

Analysis of the attacks revealed that malware was injected into the browsers of users when web traffic reached China Unicom or China Telecom networks – both state-owned telecommunications companies – “at the same points in these routes that censor traffic for the Chinese government.”

“The location of the [man-in-the-middle] system on backbone networks operating censorship equipment indicates that the [man-in-the-middle] attack could not have occurred without some level of cooperation by the administrators of these systems,” the Alert said.

“The malicious Javascript would direct the unsuspecting user’s browsers to make repeated requests to targeted U.S.-based websites.”

While the FBI Flash Alert did not specify which company’s websites were attacked, it is likely that the popular web-based software developers collaboration platform GitHub was among those targeted.

Researchers from the University of California at Berkeley, the University of Toronto, and Princeton recently published details of a powerful Chinese MitM tool dubbed the “Great Cannon,” which was used in DDoS attacks targeting websites operated by the anti-censorship project GreatFire.org, and later connected to the attacks on GitHub.

“Specifically, the Cannon manipulates the traffic of ‘bystander’ systems outside China, silently programming their browsers to create a massive DDoS attack,” the researchers said.

“The operational deployment of the Great Cannon represents a significant escalation in state-level information control: the normalization of widespread use of an attack tool to enforce censorship by weaponizing users.”

GitHub was likely targeted because GreatFire.org had begun to mirror some content on the platform. The attacks against GreatFire employed the same techniques as those seen in the GitHub attack, which leveraged hijacked Internet traffic.

“The web browser’s request for the Baidu javascript is detected by the Chinese passive infrastructure as it enters China. A fake response is sent out from within China instead of the actual Baidu Analytics script. This fake response is a malicious javascript that tells the user’s browser to continuously reload two specific pages on GitHub.com,” analysis of the attack revealed.

This analysis aligns with details of the GreatFire.org attacks which was released previously.

“Millions of global internet users, visiting thousands of websites hosted inside and outside China, were randomly receiving malicious code which was used to launch cyber-attacks against GreatFire.org’s websites. Baidu’s Analytics code (h.js) was one of the files replaced by malicious code which triggered the attacks,” officials at GreatFire.org said.

“Baidu Analytics, akin to Google Analytics, is used by thousands of websites. Any visitor to any website using Baidu Analytics or other Baidu resources would have been exposed to the malicious code.”

GreatFire.org said it has conclusive evidence that the Chinese government using the nation’s infrastructure to conduct the attacks, and had previously published a detailed report, which was further backed up by the analysis provided by the university researchers.

“We show that, while the attack infrastructure is co-located with the Great Firewall, the attack was carried out by a separate offensive system, with different capabilities and design, that we term the Great Cannon,” the researchers wrote.

“The Great Cannon is not simply an extension of the Great Firewall, but a distinct attack tool that hijacks traffic to (or presumably from) individual IP addresses, and can arbitrarily replace unencrypted content as a man-in-the-middle.”

 

 

Credit:  Anthony M. Freed

PayPal Remote Code Execution Vulnerability

 

 

A critical remote code execution vulnerability has been reported in the eBay owned global e-commerce business PayPal that could be exploited by an attacker to execute arbitrary code on the PayPal’s Marketing online-service web-application server.
The remote code execution flaw, discovered by an independent security researcher, Milan A Solanki, has been rated Critical by Vulnerability Lab with a CVSS count of 9.3 and affected the marketing online service web-application of PayPal.
The vulnerability resides in the Java Debug Wire Protocol (JDWP) protocol of the PayPal’s marketing online service web-server.

 

[Video] PayPal Remote Code Execution Vulnerability Demonstrated by Hacker

 

Successful exploitation of the PayPal vulnerability could result in an unauthorized execution of system specific codes against the targeted system in order to completely compromise the company’s web server, without any privilege or user interaction.
JDWP is a protocol that used for communication between a debugger and the Java virtual machine that it debugs. It is one layer of the Java Platform Debugger Architecture (JPDA).

 

However, JDWP does not use any authentication, but could be abused by hackers to execute arbitrary code remotely onto the affected Web server.
Solanki also provided a proof-of-concept video to demonstrate the hack in action. He used the jdwp-shellifier tool from Github to scan the marketing sites and found opened port 8000.

 

 

The opened port 8000 made him establish a connection to the service without any authentication that allowed him to execute his server-side codes with root privileges. This is nothing but a successful exploitation of the remote code execution flaw.

 

Solanki reported the vulnerability to the PayPal developer team, and without any long delay, the team fixed the flaw within four days after receiving the details from security researcher.

 

Credit:

 

Tesla’s Site And Twitter Account Hacked

 

Looks like it’s going to be a rough Saturday for Tesla’s IT department: they’ve just had both their website and Twitter account hijacked.

Update, 3:50 P.M: Tesla CEO Elon Musk’s personal Twitter account was seemingly hijacked briefly around this time, as well.

The first signs of the hijacking popped up around 1:52 P.M. pacific, when a tweet from the account declared that it was now under the control of its attackers, and the account’s name was changed from “Tesla Motors” to “#RIPPRGANG”.

A few minutes later, the account began promising free Teslas to those who followed certain accounts or to those who called a certain phone number. A quick search suggests that the number belongs to a computer repair shop in Illinois, and was presumably tweeted out to flood the number’s owner with calls. We’ve censored the number in the above screenshot for obvious reasons.

At nearly the same time, Tesla’s website was edited to declare that it’d been hacked by the same attackers. As of 2:15 p.m., the site had been taken offline — but in the hours since, it’s returned with the hijacked page multiple times. Its Twitter account, meanwhile, still seems to be hijacked. (We’ve avoided linking directly to any of the hacked sites in the off chance that the sites themselves were made to compromise the user’s security.)

Update: At around 2:45 P.M pacific, or roughly an hour after the Twitter account was compromised, it was restored. Tesla’s site is still offline.

It’s not unusual for a high-profile Twitter account to get hijacked — many of the most followed accounts in the world have fallen at one time or another. Taylor Swift’s account, for example, was hacked just weeks ago. That both Tesla’s Twitter account and the website were hacked simultaneously, though, points to an issue beyond a one-off Twitter security failing.

It’s unclear if the hack compromised the security of Tesla’s own servers, or if the site hijacking is a result of something like DNS/domain redirection. We’ve reached out to Tesla for comment here.

 

Critical SSL Vulnerability Leaves 25,000 iOS Apps Vulnerable to Hackers

Critical SSL Vulnerability Leaves 25,000 iOS Apps Vulnerable to Hackers
A critical vulnerability resides in AFNetworking could allow an attacker to cripple the HTTPS protection of 25,000 iOS apps available in Apple’s App Store via man-in-the-middle (MITM) attacks.
AFNetworking is a popular open-source code library that lets developers drop networking capabilities into their iOS and OS X products. But, it fails to check the domain name for which the SSL certificate has been issued.
Any Apple iOS application that uses AFNetworking version prior to the latest version 2.5.3 may be vulnerable to the flaw that could allow hackers to steal or tamper data, even if the app protected by the SSL (secure sockets layer) protocol.

 

Use any SSL Certificate to decrypt users’ sensitive data:
An attacker could use any valid SSL certificate for any domain name in order to exploit the vulnerability, as long as the certificate issued by a trusted certificate authority (CA) that’s something you can buy for $50.

This meant that a coffee shop attacker could still eavesdrop on private data or grab control of any SSL session between the app and the Internet,” reports SourceDNA, a startup company that provides code analysis services.

Like, for example, I can pretend to be ‘facebook.com‘ just by presenting a valid SSL certificate for ‘thehackernews.com.
The vulnerability, which is estimated to affect more than 25,000 iOS apps, was discovered and reported by Ivan Leichtling from Yelp.
AFNetworking had fixed the issue in its latest release 2.5.3 before the previous version 2.5.2, which fails to patch another SSL-related vulnerability.

 

Version 2.5.2 Failed to Patch the issue:
Previously it was believed that with the release of AFNetworking 2.5.2, the lack of SSL certificate validation issue had been eliminated that allowed hackers with self-signed certificates to intercept the encrypted traffic from vulnerable iOS apps and view the sensitive data sent to the server.
However, even after the vulnerability was patched, SourceDNA scanned for vulnerable code present in iOS apps and found a number of iOS apps till then vulnerable to the flaw.

 

Therefore, anyone with a man-in-the-middle position, such as a hacker on an unsecured Wi-Fi network, a rogue employee inside a virtual private network, or a state-sponsored hacker, presenting their own CA-issued certificate can monitor or modify the protected communications.

 

Apps from Big Developers found to be vulnerable. SERIOUSLY?
A quick check for iOS products with the domain name validation turned off; the security company found apps from important developers, including Bank of America, Wells Fargo, and JPMorgan Chase, likely to be affected.
SourceDNA also said that the iOS apps from top developers such as Yahoo and Microsoft, meanwhile, remained vulnerable to the HTTPS-crippling bug.
 
Prevention against the flaw:
Just to prevent hackers from exploiting the vulnerability, SourceDNA has not disclosed the list of vulnerable iOS apps.
However, the company advised developers to integrate the latest AFNetworking build (2.5.3) into their products in order to enable domain name validation by default.
SourceDNA is also offering a free check tool that could help developers and end users check their apps for the vulnerability.

 

Meanwhile, iOS users are also advised to check immediately the status of apps they use, especially those apps that use bank account details or any other sensitive information.
And before the developers of vulnerable apps release an update, users should avoid using any vulnerable version of the apps for the time being.

 

Hijacking SSH to Inject Port Forwards

During red team post exploitation I sometimes run into jump boxes leading to test environments, production servers, DMZs, or other organizational branches. As these systems are designed to act as couriers of outbound traffic, hijacking SSH sessions belonging to other users can be useful. So what do you do when you have full control over a jump box and want to leverage another user’s outbound SSH access to tunnel into another segment? What if you don’t have passwords, keys, shouldn’t drop binaries, and SSH is protected by 2-factor authentication? Roll up your sleeves and trust your command line Kung Fu!

This post will cover two approaches to hijacking SSH sessions, without credentials, with the goal inserting dynamic port forwards on the fly. The two stages at which I’ll approach hijacking sessions are: (1) upon session creation, and (2) when a live SSH session exists inside of screen (more common than you’d think). In each case our final goal is to create a tunnel inside another user’s active session in order to gain access to outbound routes on the terminating SSHD host.

Hijacking SSH on Creation:

To hijack newly created SSH sessions we can leverage a feature known as SSH multiplexing. This feature allows for the creation of control sockets that enable an attacker to create their own sessions inside the original user’ socket, without re-authentication. The ControlMaster feature was introduced in OpenSSH 4, and has was previously referenced in H D Moore and Val Smith’s Tactical Exploitation presentation. I also demonstrated the attack in a talk/class of mine entitled, The Poor Man’s Rootkit. In this post I will show two means to force the creation of master sockets, and then how to inject port forwards into them.

 

ControlMaster via SSH Client Config:

The most common way to deploy ControlMaster sockets is by altering the system wide SSH client config.

Inserting ControlMaster options into ssh_config on hop_1

These settings will cause all new SSH sessions to create a persistent brokering master socket.
I’ve used %h in control socket commands to represent the target host, %h can be any char(s).

Master socket created in ControlPath
Connecting to the socket:

This socket can be used to create further sessions, without credentials, even after the original user exits their session.

Creating a session using a master socket.
Adding a dynamic tunnel:
Remember our end goal is to pivot into other network segments. The following command will create a dynamic tunnel inside an existing master socket.

Dynamic port forward added to live socket

Removing the socket:

Simply exiting the multiplexed sessions will not close the master socket. In order to close the socket you must explicitly send an exit request.

Shutting down the master socket

 

SSH ControlMaster via Shell Functions:

Another way to leverage this hijacking technique, that I haven’t seen shared before, is by abusing the fact that master sockets may be created through SSH client option flags. As such, we can use a shell function to intercept a user’s SSH client commands and inject our own ControlMaster arguments.
ssh () 
{ 
    /usr/bin/ssh -o "ControlMaster=auto" -o "ControlPath=/tmp/%r@%h:%p" -o "ControlPersist=yes" "$@";
}

A simple ControlMaster injecting wrapper function.

This intercepting wrapper function will create sockets identical to those we created using ssh_config.
Successfully injecting ControlMaster options into an SSH client command

 

Flow of traffic in this attack:

Using SSH ControlMaster sockets and socket options we can now hijack SSH sessions and inject port forwards, all without authentication.
Now to tackle sessions in progress…

Hijacking Active SSH Sessions:

It is not uncommon for users to create screen sessions to house SSH connections to other boxes they are working on. What most users do not realize is that these session can be hijacked and have port forwards injected into them on the fly.Hunting for screen sessions: 
One way to find screen sessions is to look under /var/run/screen. Or you can enumerate a single user by issuing an incomplete screen -r command.
Hunting for screen sessions
Bypassing screen pts/tty restrictions:
Accessing the screen sessions of another user is not as straight forward su’ing and viewing; this is where many attackers give up. su to a user to interact with their screen session and you will find yourself staring at one of the following errors: “Cannot open your terminal ‘/dev/pts/#’ – please check.” or “Must be connected to a terminal.”
Error when trying to access another user’s screen session
One way to bypass this restriction is to use the script binary to wrap the su’d user session.
Using script to bypass screen pts/tty restrictions

 

Adding a tunnel on the fly:
A rarely used feature of SSH is the escape sub-shell. If you are using a means other than SSH to control your access to the jump box you can leverage escape sequences to add port forwards into another user’s established session. Use ~C to drop into the SSH sub-shell, then -D:<port> to add a dynamic forward on the fly. To remove the forward use ~C followed by -KD:<port>
Adding port forwards with SSH escape commands
If you are using SSH for your primary shell the above example will not work from inside screen.This is due to the fact that your own outermost SSH client will catch the escape characters. Not to worry, I’ll show you a way around that!

 

Creating tunnels with screen stuffing:
Screen has a feature that allows you to “Stuff” the contents of a buffer into its input queue. The stuffed text is parsed as if it had been typed from inside screen, allowing us to bypass escape characters being caught by outer SSH sessions.
Stuffing screen to create a port forward
Stuffing screen to shutdown a port forward

A note on stealthy stuffing: Stuff’d text is visible inside a screen session’s scroll back. You can prevent this by altering the scroll back length on the fly. This can be done by changing the scrollback to 0 lines before your command, clearing the screen, then setting it back.
screen -S my_ssh_session -X scrollback 0
screen -S my_ssh_session -p 0 -X stuff $'~C'
screen -S my_ssh_session -p 0 -X stuff $'-D:9090\nclear\n'
screen -S my_ssh_session -X scrollback 15000

 

Flow of traffic in screen hijack attack:

Thanks to SSH escapes and screen stuffing we now have a means to hijack established sessions and inject tunnels on the fly!

Tunneling into Remote Segments:

The final step is to bind a local port on our machine to connect us to the tunnel we injected on hop_1.
We now have a full dynamic tunnel into the remote segment, without authentication.

Local port forward on attacker machine via SSH escapes.

 

Credit: 0xthem