Researchers Earn $100,000 for Hacking Pixel Phone

A team of researchers has earned more than $100,000 from Google for an Android exploit chain that can be used to hack the company’s Pixel phone remotely simply by getting the targeted user to access a malicious website.

Google’s Pixel phone was the only device that was not hacked at last year’s Mobile Pwn2Own competition. However, researcher Guang Gong of Chinese security firm Qihoo 360 and his team did manage to find a couple of vulnerabilities that can be chained for a remote code injection exploit that works against Pixel and other Android smartphones.

The exploit relies on two vulnerabilities: CVE-2017-5116 and CVE-2017-14904. The former is a type confusion flaw in the V8 open-source JavaScript engine and it can be exploited for remote code execution in a sandboxed Chrome render process. Google patched this security hole in September with the release of Chrome 61.

The second vulnerability affects Android’s libgralloc module and it can be exploited to escape the Chrome sandbox. This privilege escalation flaw was patched by Google in December with its monthly Android updates.

Combining the two vulnerabilities allows an attacker to inject arbitrary code into the system_server process by getting the targeted user to access a malicious URL in Chrome.

Gong and his team earned $105,000 for the exploit chain through the Android Security Rewards (ASR) program, and an additional $7,500 through the Chrome bug bounty program. This is the highest reward in the history of the ASR program, which is not surprising considering that it has been paid out for the first remote exploit chain since the ASR program was expanded last summer.

Google announced at the time that rewards for remote exploit chains or exploits leading to TrustZone or Verified Boot compromise increased to $200,000, and bounties for remote kernel exploits increased to $150,000.

Gong has published a guest post on Google’s security and Android developers blogs detailing both vulnerabilities and how the exploit chain works.

Eduard Kovacs is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/Ix-zdew7uaw/researchers-earn-100000-hacking-pixel-phone

New botnet infects cryptocurrency mining computers, replaces wallet address

Satori—the malware family that wrangles routers, security cameras, and other Internet-connected devices into potent botnets—is crashing the cryptocurrency party with a new variant that surreptitiously infects computers dedicated to the mining of digital coins.

A version of Satori that appeared on January 8 exploits one or more weaknesses in the Claymore Miner, researchers from China-based Netlab 360 said in a report published Wednesday. After gaining control of the coin-mining software, the malware replaces the wallet address the computer owner uses to collect newly minted currency with an address controlled by the attacker. From then on, the attacker receives all coins generated, and owners are none the wiser unless they take time to manually inspect their software configuration.

Records show that the attacker-controlled wallet has already cashed out slightly more than 1 Etherium coin. The coin was valued at as much as $1,300 when the transaction was made. At the time this post was being prepared, the records also showed that the attacker had a current balance of slightly more than 1 Etherium coin and was actively mining more, with a calculation power of about 2,100 million hashes per second. That’s roughly equivalent to the output of 85 computers each running a Radeon Rx 480 graphics card or 1,135 computers running a GeForce GTX 560M, based on figures provided here.

Assuming the wallet address continues to generate coins at the same rate, the proceeds after a few months could be well worth the effort, assuming the massive cryptocoin sell-off—which has caused Etherium’s value to drop by 42 percent in the past four days—doesn’t continue.

Satori: Not just for IoT anymore

Satori is a modified version of the open source Mirai botnet malware. Mirai took control of so-called Internet-of-Things devices and caused them to participate in distributed denial-of-service attacks that paralyzed large swaths of the Internet in 2016. When Satori appeared in December, the underlying code was significantly overhauled. Instead of infecting devices that were secured with easily guessable default passwords, it exploited programming vulnerabilities in the device firmware. In early December, Satori had infected more than 100,000 devices and reportedly grew much bigger in the following weeks.

According to a Netlab 360 researcher who goes by the name RootKiter and wrote in Wednesday’s post, the Satori version that appeared on January 8 continues to exploit two IoT vulnerabilities. But, RootKiter continued, the new version also exploits the weakness in the Claymore Mining software.

It’s not clear precisely how the new variant is infecting mining computers. At least one vulnerability has been reported in the Claymore Mining software, along with a corresponding vulnerability. Wednesday’s post said Satori isn’t exploiting it. Instead, Wednesday’s post said Satori “works primarily on the Claymore Mining equipment that allows management actions on 3333 ports with no password authentication enabled (which is the default config).”

To prevent further abuse, Netlab 360 said it wasn’t providing further details. Developers of the Claymore Mining software didn’t respond to an email seeking comment for this post.

Oddly, the developer of the new variant left a message on infected computers that reads:

Satori dev here, dont be alarmed about this bot it does not currently have any malicious packeting purposes move along. I can be contacted at curtain@riseup.net

The message is demonstrably untrue, since malware that uses other people’s computers and electricity to mine cryptocurrency is by definition malicious.

https://arstechnica.com/?p=1245947

Zyklon Malware Delivered via Recent Office Flaws

A piece of malware known as Zyklon has been delivered by cybercriminals using some relatively new vulnerabilities in Microsoft Office, FireEye reported on Wednesday.

Zyklon has been around since early 2016 and it allows attackers to conduct a wide range of malicious activities, including launch distributed denial-of-service (DDoS) attacks, log keystrokes, steal passwords, and mine cryptocurrency.

A recent campaign observed by FireEye has been aimed at organizations in the telecommunications, insurance and financial services sectors. The malware has been delivered as a ZIP archive attached to spam emails.

The ZIP file contains a specially crafted Word document that exploits one of three weaknesses in Microsoft Office to deliver a PowerShell script that downloads the final Zyklon payload from a remote server.

One of the vulnerabilities exploited by the malicious documents is CVE-2017-8759, a flaw patched by Microsoft in September 2017 after FireEye noticed that it had been exploited to deliver spyware. The security hole was later used by China-linked cyberspies to target organizations in the United States.

Another flaw exploited to deliver Zyklon is CVE-2017-11882, a 17-year-old vulnerability in the Equation Editor component that Microsoft patched in November. CVE-2017-11882 has been leveraged by Iranian cyberspies, the Cobalt hacking group, and others.

Cybercriminals have also abused the Dynamic Data Exchange (DDE) feature in Office to spread the malware. Russia-linked cyberspies and many other threat actors have abused DDE to deliver malware, which ultimately led to Microsoft disabling the feature in all versions of Word in an effort to prevent attacks.

If the malicious documents successfully exploit one of these weaknesses, they download a PowerShell script that injects code and fetches the final payload from a server.

The malware uses the Tor network to communicate with its command and control (C&C) server. Once a connection has been established, the attacker can instruct the malware to provide information about the infected system, launch DDoS attacks, mine cryptocurrency, and upload harvested data.

In addition to built-in functionality, Zyklon has several plugins that can be loaded for additional features. The plugins allow attackers to steal passwords from popular web browsers, FTP and email passwords, keys associated with video games, and software license keys.

The malware can also establish a Socks5 proxy on the infected machine, and it can hijack the clipboard in order to replace Bitcoin addresses copied by the victim with addresses owned by the attacker.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/DYrL6p4rn9M/zyklon-malware-delivered-recent-office-flaws

Stack Ranking SSL Vulnerabilities: The ROBOT Attack

At least two additional security vendors, including IBM and Palo Alto Networks, have been added to the list of vendors vulnerable to a variation on the Bleichenbacher attack called the ROBOT attack.

The attack was published by a trio of researchers, Hanno Böck, Juraj Somorovsky, and Craig Young. They dusted off the old Bleichenbacher attack against RSA key exchanges and ran it against a set of modern TLS stacks, finding that some were vulnerable. They contacted each of the vulnerable websites they found, and worked with the underlying TLS stack vendors, following the proper disclosure process.

They’ve published their research in a paper titled “Return Of Bleichenbacher’s Oracle Threat Or how we signed a Message with Facebook’s Private Key.“ In the tradition of named TLS protocol vulnerabilities that started with Heartbleed, the ROBOT attack has its own website and logo.

Disclaimer: the company I work for, F5 Networks, is vulnerable to this class of attacks. I’m put in the somewhat precarious position of judging this vulnerability and trying to stay neutral. If anything, I think my scoring system below betrays the significance of this vulnerability; but by how much is an open question.

Everything old is new again.

The Bleichenbacher “million message attack” (PDF) isn’t actually new: primers on SSL/TLS mentioned it as early as 1998. The original padding oracle attack for TLS, Bleichenbacher sends thousands of variations of ciphertext at a TLS server. The TLS server attempts to decrypt each one, and sends back one of two error codes—either the decrypt failed, or the padding was messed up. By trying many variations of a message containing a third-party’s TLS session, and differentiating between the two error codes, the attacker could eventually reconstruct the session, one bit at time. Within that TLS session the attacker might find user credentials, and then the breach is on. Bleichenbacher has since been refined (PDF) to the point where this version requires only tens of thousands of attempts.

The Bleichenbacher attack raises its head every now and then. Filippo Valsorda found one in the python-rsa library in 2016. A German team found one in XML encryption in 2012. Another German team wrote about optimizations for Bleichenbacher in this 2014 paper (PDF).

(In fact, Bleichenbachers come up often enough that I had trouble figuring out how to title this article because “revenge of” and “strikes again” and “revisiting” for Bleichenbacher were all taken.)

What’s the impact?

Bleichenbacher is a neat little theoretical protocol attack. However, to my knowledge, no real Bleichenbacher attack has ever been seen in the field.

Forward secret ciphers (ECDHE and DHE) aren’t vulnerable to RSA Bleichenbacher’s and 90% of today’s popular TLS stacks prefer forward secrecy, which is also supported by all major browsers. So the scope of the vulnerability is limited to two classes of users. Those that are using RSA because for legacy reasons (think Windows XP users in the third world) or organizations that specifically disallow forward secrecy because of passive monitoring requirements. Many financial organizations fall into this category, and their end-users are the ones most at risk.

Forward Secrecy Chart

86% of internet hosts prefer forward secrecy; all modern browsers do, too

The researchers claim that their proof-of-concept code can get the server to sign an arbitrary message. The obvious thing to do would be to get the oracle to sign an active TLS handshake, allowing for a real TLS man-in-the-middle attack a la LOGJAM. But an attacker could (probably) not do an MitM in real time. Even the optimized Bleichenbacher attack requires tens of thousands and that’s its biggest limitation. Running the researchers’ POC code took 12 hours on my virtual test harness. Fast server hardware gets it down to six hours, but after LOGJAM, administrators figured they should bound the SSL handshake by 6 seconds or less to avoid this kind of problem.

The other obvious target would be to get the Bleichenbacher padding oracle to decrypt someone else’s pre-master-secret, and use that to crack a recorded TLS session. That’s a real possibility with this optimized attack, and one that should be mitigated ASAP.

How does this Bleichenbacher score?

I try to provide a relative ranking of SSL/TLS vulnerabilities, independent of the CVSS scoring. My ranking is for enterprise architects with a specific focus on TLS. The numbers generated aren’t necessarily the important part; it’s the relative ranking to other vulnerabilities. So far, Heartbleed remains the worst of all time, with nothing even in the same class.

If this Bleichenbacher is used to crack a session, then its impact score is:

ROBOT stack rank score = 15

– Impact = session key derivation = 3

– Exploitability = requires MiTM and thousands of messages = 5

Vulnerability Impact Score Chart

Mitigation Strategies

There are at least three mitigations for this edition of the Bleichenbacher attack.

First, if your TLS server manufacturer has issued patches, go get them and patch your appliances or software.

The second option is to require only forward-secret (non RSA) key exchange ciphers. Bleichenbacher only works against RSA handshakes, so elliptic curve and Diffie-Hellman handshakes are safe. Most of the Internet already supports (and prefers) forward secrecy, so some sites may opt for this solution. Whether you decide to is up to you—I would measure the percentage of your browsers still connecting with RSA before you make that call. RSA certificates used with forward secret ciphers are still okay.

The third option is to rate-limit SSL handshakes from individual IP addresses. If your TLS solution has a programmable data plane, a simple rule that tracks outstanding TLS requests per flow is sufficient. As a result of the LOGJAM attack from 2015, you should already be limiting TLS connection handshakes to 10 seconds or less.

Why does this keep happening?

If we all knew about Bleichenbacher as early as SSLv3, why do implementations keep falling prey to it? One reason is that TLS implementers are just nice. They write code that tries to tell you why the server rejected your message. Maybe that information would be useful to the implementer of the client side. Have you ever tried to debug a problem where the other side wouldn’t give you any useful information other than “bad input”?

In order to foil padding oracle attacks (and their uglier cousins, timing oracle attacks), implementers need to return a single error code (just pick one) and take the same amount of time to validate the input, no matter what kind of malicious input was given.

There is a proper way to do that. Instead of parsing the incoming message, the implementer of the server needs to construct a copy of what it expects to find, and then compare the incoming message to the copy. If they match, great. If not, then it should return a single error code. This fixes padding oracles and timing oracles too. But that’s next-level thinking that only fairly sophisticated infosec types have experience with. A basic, or even intermediate, programmer isn’t going to be thinking that far ahead when building a crypto library or server.

The researchers note that there do not appear to be any easy-to-run Bleichenbacher unit tests available in today’s crypto testing frameworks and conclude that few people test for them. There is no easy, free X509 parser for Python2, for example, which many testing frameworks use.

Will this be the last Bleichenbacher?

The forthcoming TLS 1.3 protocol requires forward-secret ciphers, so it will be safe from RSA Bleichenbacher attacks. But I expect adoption of TLS 1.3 to be somewhat slow, because forward secrecy isn’t free and introduces major visibility problems for enterprises with significant SSL inspection investments.

I expect TLS 1.2 and its support of RSA handshakes to be around for several more years. And at the current rate of a Bleichenbacher every couple of years, I guess we have a few more to see.

David Holmes is an evangelist for F5 Networks‘ security solutions, with an emphasis on distributed denial of service attacks, cryptography and firewall technology. He has spoken at conferences such as RSA, InfoSec and Gartner Data Center. Holmes has authored white papers on security topics from the modern DDoS threat spectrum to new paradigms of firewall management. Since joining F5 in 2001, Holmes has helped design system and core security features of F5’s Traffic Management Operating System (TMOS). Prior to joining F5, Holmes served as Vice President of Engineering at Dvorak Development. With more than 20 years of experience in security and product engineering, Holmes has contributed to security-related open source software projects such as OpenSSL. Follow David Holmes on twitter @Dholmesf5.

Previous Columns by David Holmes:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/l492al7kcp0/stack-ranking-ssl-vulnerabilities-robot-attack

Threat Actors Quickly Adopt Effective Exploits

Cybercriminals and nation state groups were quick to adopt the most effective exploits last year, a new AlienVault report reveals.

Not only do the most effective exploits proliferate quickly between cybercriminals, but some of them remain popular for years after their initial discovery.

The top 10 list of exploits – by number of occurrences in vendor reports – is dominated by Microsoft Office and Microsoft Windows, data from AlienVault’s Open Threat Exchange (OTX) platform reveals. Adobe Flash, Microsoft .NET, and Android/Linux were also present on the list, with one exploit each.

The exploit to appear most often in vendor reports last year was CVE-2017-0199, a code execution bug affecting Microsoft Office. Detailed in April 2017, when it was already being abused in attacks, the vulnerability started being adopted almost immediately, and the trend continued toward the end of the year as well.

The popularity of this exploit continued to grow even after Microsoft released a patch. Originally abused with malicious Rich Text File (RTF) documents, the flaw was leveraged with PowerPoint Slide Show files by August, and threat actors continued to use it in this manner in the following months as well.

Some attackers combined multiple exploits to avoid detection, using CVE-2017-0199 together with CVE-2012-0158, an old Office flaw that is still exploited in many campaigns and which made it to the third position on AlienVault’s top 10 exploits for last year.

The second place went to CVE-2015-1641, an exploit that was already highly popular one year after it became public. Actors exploiting the vulnerability include the Patchwork cyberespionage group and cybercriminals located in Nigeria.

In addition to CVE-2017-0199, three other exploits discovered in 2017 were among the most reported by vendors, namely CVE-2017-0144, CVE-2017-0262, and CVE-2017-8759. A .NET zero-day, CVE-2017-8759 was patched in September, after it was abused to deliver the FinFisher malware to Russian-speaking individuals.

The only exploit targeting operating systems other than Windows that made it to AlienVault’s top 10 list is CVE-2013-6282, targeting a bug leveraged by Android malware to escalate privileges once installed on a victim’s phone.

A Windows 2000 flaw reported in 2001 was encountered the most by AlienVault’s customers, the company reports. Two vulnerabilities from 2017 made it to the top 10 list of exploits seen the most, namely CVE-2017-0144 and CVE-2017-5638 (an Apache Struts bug).

“This data-set is very large, and consists of many billions of security events. However the data is heavily biased towards “noisy” network based exploit attempts from worms and exploit scanners. This explains why we’re still recording ancient vulnerabilities from 2001 in this table,” AlienVault points out.

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/j-ndbbEdscM/threat-actors-quickly-adopt-effective-exploits

Oracle Fixes Spectre, Meltdown Flaws With Critical Patch Update

Oracle on Tuesday released its first Critical Patch Update for 2018 to deliver 237 new security fixes across its product portfolio. Over half of the addressed vulnerabilities could be remotely exploited without authentication.

As part of the January 2018 Critical Patch Update, Oracle released fixes for the Critical processor vulnerabilities made public in the beginning of the year, namely Spectre and Meltdown. Impacting modern processors, the bugs put billions of devices at risk, and vendors have been working hard to address them over the past several weeks.

“The January 2018 Critical Patch Update provides fixes for certain Oracle products for the Spectre (CVE-2017-5753, CVE-2017-5715) and Meltdown (CVE-2017-5754) Intel processor vulnerabilities,” Oracle notes in its advisory. Specific details, however, are included in a separate note, accessible only to its customers.

The security updates Oracle released for the Sun Systems Products Suite also include a fix for Oracle X86 Servers to address the CVE-2017-5715 Spectre flaw. The fix “includes Intel microcode that enables OS and VM level mitigations,” but the patch is necessary only for servers using non Oracle OS and Virtualization software.

“Oracle OS and Oracle VM patches for CVE-2017-5715 will include updated Intel microcode,” the company said.

A patch for the same bug was also included in the security updates for Oracle VM VirtualBox.

An article from The Register claims that Oracle admitted in a document on its customer portal that Solaris on SPARCv9 might be impacted by the Spectre flaws. The company reportedly said that patches are being developed, but didn’t provide information on when they would be released or on the performance impact they might have.

The product with the largest number of fixes in the January 2018 Critical Patch Update is Financial Services Applications, at 34 patches. 13 of the flaws could be remotely exploitable without authentication.

Fusion Middleware was the second most impacted Oracle product, at 27 fixes (21 of the bugs being remotely exploitable without authentication), followed by MySQL (25 fixes – 6 remotely exploitable bugs), and Java SE (21 – 18) and Hospitality Applications (21 – 15).

Oracle also resolved bugs in PeopleSoft Products (15 – 8), Supply Chain Products Suite (14 – 12), Virtualization (14 – 3), Sun Systems Products Suite (13 – 7), Retail Applications (11 – 8), Communications Applications (10 – 8), Health Sciences Applications (7 – 5), E-Business Suite (7 – 4), Database Server (5 – 3), Hyperion (4 – 1), Support Tools (3 – 1), JD Edwards Products (2 – 2), Siebel CRM (2 – 0), Construction and Engineering Suite (1 – 0), and Java Micro Edition (1 – 0).

Affecting Apache Log4j, CVE-2017-5645 was the vulnerability with the largest number of occurrences in this set of patches, at 21. It affects Communications Applications, WebLogic Server, PeopleSoft Products, Retail Applications, and Supply Chain Products Suite.

The vulnerability with the highest CVSS score (10) was addressed in Sun ZFS Storage Appliance Kit (AK). The most commonly encountered CVSS score of the addressed vulnerabilities was 9.8. Over 20 such flaws were found in Communications Applications, Fusion Middleware, PeopleSoft, Retail Applications, and Virtualization products.

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/_oV-2ch0NMA/oracle-fixes-spectre-meltdown-flaws-critical-patch-update

DNS Servers Crash Due to BIND Security Flaw

Updates released by the Internet Systems Consortium (ISC) for BIND patch a remotely exploitable security flaw that has caused some DNS servers to crash.

The high severity vulnerability, tracked as CVE-2017-3145, is caused by a use-after-free bug that can lead to an assertion failure and crash of the BIND name server (named) process.

“BIND was improperly sequencing cleanup operations on upstream recursion fetch contexts, leading in some cases to a use-after-free error that can trigger an assertion failure and crash in named,” ISC said in an advisory.

While there is no evidence that this vulnerability has been exploited in malicious attacks, ISC says crashes caused by the bug have been reported by “multiple parties.” The impacted systems act as DNSSEC validating resolvers, and temporarily disabling DNSSEC validation can be used as a workaround.

The vulnerability, discovered by Jayachandran Palanisamy of Cygate AB, affects BIND versions 9.9.9-P8 to 9.9.11, 9.10.4-P8 to 9.10.6, 9.11.0-P5 to 9.11.2, 9.9.9-S10 to 9.9.11-S1, 9.10.5-S1 to 9.10.6-S1, and 9.12.0a1 to 9.12.0rc1. It has been patched with the release of BIND 9.9.11-P1, 9.10.6-P1, 9.11.2-P1 and 9.12.0rc2.

“Addresses could be referenced after being freed during resolver processing, causing an assertion failure. The chances of this happening were remote, but the introduction of a delay in resolution increased them. (The delay will be addressed in an upcoming maintenance release.),” ISC explained.

The organization has also informed users of CVE-2017-3144, a medium severity DHCP vulnerability affecting versions 4.1.0 to 4.1-ESV-R15, 4.2.0 to 4.2.8, and 4.3.0 to 4.3.6.

“By intentionally exploiting this vulnerability an attacker who is permitted to establish connections to the OMAPI control port can exhaust the pool of socket descriptors available to the DHCP server,” ISC explained.

“Once exhausted, the server will not accept additional connections, potentially denying access to legitimate connections from the server operator. While the server will continue to receive and service DHCP client requests, the operator can be blocked from the ability to use OMAPI to control server state, add new lease reservations, etc.,” it added.

ISC has developed a patch and it plans on adding it to a future maintenance release of DHCP. In the meantime, users can protect themselves against potential attacks by disallowing access to the OMAPI control port from unauthorized clients. Alternatively, organizations can obtain the patch from ISC and integrate it into their own code.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/nUGu-IIf3gY/dns-servers-crash-due-bind-security-flaw

Mirai Variant Targets ARC CPU-Based Devices

A newly discovered variant of the Mirai Internet of Things (IoT) botnet is targeting devices with ARC (Argonaut RISC Core) embedded processors, researchers warn.

Dubbed Okiru, the new malware variant appears to be different from the Satori botnet, although the latter was also called Okiru by its author. Security researchers analyzing the new threat have discovered multiple differences between the two Mirai versions, aside from the targeting of the ARC architecture.

Originally designed by ARC International, the ARC processors are 32-bit CPUs widely used in system on chip (SOC) devices for storage, home, mobile, automotive, and IoT applications. Each year, over 1.5 billion devices are shipped with ARC processors inside.

Mirai Okiru represents the very first known malware targeting ARC processors, independent security researcher Odisseus, who analyzed the threat, notes.

The botnet was discovered by @unixfreaxjp from malwaremustdie.org, the security researcher who spotted the first Mirai variant in August 2016. In a post on reddit, the researcher explained that, although distributed denial of service (DDoS) is the main purpose of the last two Mirai versions, they are very different.

One of the characteristics that sets them apart is the configuration, which in Okiru is encrypted in two parts with telnet bombardment password encrypted. Satori doesn’t split it in two and doesn’t encrypt brute default passwords either. Moreover, the new malware variant can use up to 114 credentials for telnet attack, while Satori uses a different and shorter database.

The researcher also explains that Okiru seems to lack the “TSource Engine Query” common Distributed “Reflective” (DRDoS) attack function via random UDP that Satori has. The two also have different infection follow up commands written in their configurations and show differences in usage of watchdog.

Okiru was found to have four types of router attack exploit code hard coded in it, none of which is found in Satori. Furthermore, there are small embedded ELF Trojan downloaders in Satori, which are used to download other architecture binaries (these were coded differently compared to Okiru ones).

Last week, when the researchers first noticed Okiru’s attacks, the malware enjoyed low detection in VirusTotal. Thus, and because the new threat is targeting devices that haven’t been hit by malware previously, researchers expect an uptick in Mirai infections.

It is also clear that the actor behind the botnet is actively following reports on the malware. Within minutes after ENISA (European Union Agency for Network and Information Security) Threat Landscape Stakeholder Group member Pierluigi Paganini wrote about Okiru, the website was hit with a DDoS attack that lasted over an hour, Italy’s CERT-PA revealed (translated).

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/ksfWUiscCkY/mirai-variant-targets-arc-cpu-based-devices

Code Execution Flaw Found in Transmission BitTorrent App

Google Project Zero researcher Tavis Ormandy has discovered a critical remote code execution vulnerability in the Transmission BitTorrent client. The expert has proposed a fix, but it has yet to be implemented by the application’s developers.

Transmission is a popular open source BitTorrent client that is available for Windows, Mac and Linux. Ormandy has been analyzing several popular torrent clients and found that Transmission has a serious vulnerability.

According to the researcher, an attacker can execute code on a system running Transmission by getting the targeted user to access a specially crafted website.

“The Transmission bittorrent client uses a client/server architecture, the user interface is the client and a daemon runs in the background managing the downloading, seeding, etc,” Ormandy explained in an advisory. “Clients interact with the daemon using JSON RPC requests to a web server listening on port 9091. By default, the daemon will only accept requests from localhost.”

However, the expert showed that the localhost requirement can be bypassed using a type of attack called “DNS rebinding.”

The attacker sets up a website and adds an iframe that points to a subdomain of that site. The DNS server is configured to respond alternatively with an address controlled by the attacker and localhost (127.0.0.1), with a short time to live (TTL). When the victim visits the malicious website, the browser resolves to the attacker-controlled DNS server and then switches to localhost.

“Exploitation is simple, you could set script-torrent-done-enabled and run any command, or set download-dir to /home/user/ and then upload a torrent for ‘.bashrc’,” Ormandy explained.

The expert says he has successfully tested his proof-of-concept (PoC) exploit with Chrome and Firefox running on Windows and Linux.

The vulnerability, tracked as CVE-2018-5702, was reported to Transmission developers on November 30, and Ormandy even provided a fix the next day. However, an official patch still has not been released, which the researcher says is highly unusual for open source projects.

Ormandy pressed the developers and last week they agreed to make his patch public on GitHub so that at least downstream distributions such as Debian and Fedora can roll out their own patches. It’s unclear when an official patch will become available, but it should be included in the next 2.93 release.

Transmission developers pointed out that the macOS and Linux versions are only vulnerable if remote access is enabled; the feature is disabled by default.

Sebastian Lekies, who also works for Google, said he reported the same vulnerability to Transmission developers five years ago, but never heard back from them.

Back in 2016, hackers broke into the Transmission website and planted a malicious installer designed to deliver a new OS X ransomware.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/6BXk2uzQRJk/code-execution-flaw-found-transmission-bittorrent-app

BlackBerry Launches Security Product for Automotive, Other Industries

BlackBerry announced on Monday the launch of Jarvis, a new cybersecurity service designed to help companies in the automotive and other sectors find vulnerabilities in their software.

Jarvis has been described by BlackBerry as a cloud-based static binary code analysis software-as-a-service (SaaS) product. The tool is currently used by automakers, including Britain’s largest car maker, Jaguar Land Rover, but BlackBerry says it is ideal for other types of organizations as well, including in the healthcare, aerospace, defense, and industrial automation sectors.

Modern cars use hundreds of software components, including many provided by third-party vendors across several tiers. While this approach has some advantages, it also increases the chances of vulnerabilities making it into the software somewhere along the supply chain. BlackBerry launches Jarvis code scanning service

Jarvis aims to address this issue by scanning code and offering actionable information within minutes. In addition to finding vulnerabilities, the service also helps ensure compliance with various standards.

BlackBerry claims the new product performs tasks that would require a large number of experts and a lot of time, which should help companies save money. The tool can be integrated with existing development tools and APIs.

“Connected and autonomous vehicles require some of the most complex software ever developed, creating a significant challenge for automakers who must ensure the code complies with industry and manufacturer-specific standards while simultaneously battle-hardening a very large and tempting attack surface for cybercriminals,” said John Chen, executive chairman and CEO of BlackBerry.

“Jarvis is a game-changer for OEMs because for the first time they have a complete, consistent, and near real-time view into the security posture of a vehicle’s entire code base along with the insights and deep learning needed to predict and fix vulnerabilities, ensure compliance, and remain a step ahead of bad actors,” Chen added.

Jarvis is an online tool that can be used by companies as a pay-as-you-go service. The product can be customized for each organization’s needs and their specific supply chain, allowing them to scan code at every stage of the development process.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/VHPBy0p87ag/blackberry-launches-security-product-automotive-other-industries