Future | Biz Builder Mike

A minster’s look at regulation and innovation: A necessity to strike a balance

September 26, 2020 by bizbuildermike

Repeatedly, proponents of disruptive technologies have proven that regulation and innovation have an immense potential to actualize a mutually beneficial existence. The often delicate relationship between innovators and regulators — which may be mired by antagonism — is fundamental to the functioning of the global economy, especially at times as challenging as we are facing now.

The fuel that keeps the fire of the important relationship between regulators and businesses alight — like any — is communication and collaboration. This could not be more apt when it comes to the innovators behind distributed ledger technology and the regulators in overseeing the space.

Ideas surrounding DLT first arose in the early 90s, however, it was not until 2009 that the first block of what we now know as blockchain was mined. In 11 short years, blockchain and DLT more generally have had tremendous success in garnering attention from the financial community and the wider public. Just this year, Big Four audit firm Deloitte’s 2020 Global Blockchain Survey found that business leaders now see blockchain as “integral to organisational innovation,” while analytics agency Gartner has forecasted that blockchain technology will have generated $3.1 trillion of value-add to companies around the world by 2030.

The regulation necessity

While mainstream adoption of the blockchain industry is gathering pace, I believe it will not succeed without regulation; in fact, it needs it to survive and, indeed, to thrive. It is incumbent on regulators to strike a balance and allow companies operating in this industry with the space to continue operating at the cutting edge of innovation in a sensible and safe manner. Finding this balance and the future success of decentralized finance is inexorably linked. It will take a whole-of-industry approach where all stakeholders uphold a commitment of communication and collaboration with the regulators to ensure the harmony that the industry needs.

However, the burden of finding this balance is not just on the industry itself but on regulators and policymakers, too. Standards are commonplace across every industry, and this one is no different if it is to thrive and succeed in the main street of finance.

Meanwhile, overregulation could stifle crypto markets that are based on distributed ledger technology. Of course, it is possible to find the equilibrium point that allows the realization of the full potential of this technology within the boundaries of the regulations that govern traditional markets.

Some governments are working closely with key players in the field. In January 2018, Gibraltar became among the first jurisdictions to introduce a regulatory framework for DLT providers. Since then, the Gibraltar Financial Services Commission has awarded multiple licenses to global industry leaders, with a number of active applications currently under review. This measured regulatory response was only possible through open communication between the regulators and the innovators.

Similarly in Switzerland, its remarkably progressive stance toward cryptocurrencies and distributed ledger technologies has propelled the country ahead of the pack and closer to its aim of becoming the first “crypto nation.”

In short, there are at least 45 central banks around the world that have publicly expressed their efforts to develop central bank digital currencies by utilizing DLT. This proves that the appetite to embrace these technologies not only exists among business leaders, it is burgeoning among legislators.

There is little doubt that regulators will follow suit by working with the private industry to achieve the desired equilibrium but in order to achieve this, much more needs to be done when it comes to communication and collaboration.

The establishment of working groups between DLT companies and regulators, and government bodies and watchdogs should become commonplace.

DLT will not reach its full potential if there is still a semblance of distrust among the general public. Through open dialogue, we can work together to ensure that the market is regulated and trustworthy and that regulators have faith in the technology, while those involved in the creation and use of the technology can enjoy the immense benefits it brings.

The views, thoughts and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.

Albert Isola is Gibraltar’s minister for digital and financial services with the primary responsibility of raising Gibraltar’s profile as a well-regulated financial services center, leading the way in DLT and online gaming regulation. Minister Isola previously served as Gibraltar’s minister for commerce where he played a central role in spearheading Gibraltar’s purpose-built DLT regulatory framework, which was introduced in January 2018 for firms using blockchain to store or transfer value.

A minster\’s look at regulation and innovation: A necessity to strike a balance

Source

c0ntextomy – Let’s Debug Together: CVE-2020-9992

September 24, 2020 by bizbuildermike

c0ntextomy - Let's Debug Together: CVE-2020-9992

Apple recently released the long awaited iOS/iPadOS 14.0 update alongside an updated Xcode 12.0. As part of this update, Apple fixed a vulnerability in the Development Tools, that was reported earlier this year as a joint effort by our Zimperium zLabs researcher and VP of Product Security Nikias Bassen, and an independent security researcher, Dany Lisiansky. We named this vulnerability “c0ntextomy”.

c0ntextomy is a design flaw in MobileDevice.framework/Xcode and iOS/iPadOS/tvOS Development Tools that allows an attacker in the same network to gain remote code execution on an iOS/iPadOS/tvOS device.

The name “c0ntextomy” is derived from contextomy, which is defined as “an informal fallacy and a type of false attribution in which a passage is removed from its surrounding matter in such a way as to distort its intended meaning” [Wikipedia: contextomy]. It was chosen to reflect the way this vulnerability evolved, where the SSL context is mistakenly dismissed after an actual SSL handshake is performed, effectively making us believe that the connection is secure, even though it is in fact unencrypted.

As a result, this makes Wi-Fi debugging vulnerable to a MITM-attack, where an attacker is able to hijack a running debug session and gain arbitrary code execution on the target device.

Apple’s latest update fixes this vulnerability, however only for the latest versions of iOS and iPadOS. Older versions of iOS/iPadOS, as described below, are still partially or even fully vulnerable. We strongly advise all developers relying on Xcode’s remote developer tools (e.g. remote debugging, unit tests, etc.) to update to Xcode 12 and the devices to iOS/iPadOS 14.

The full security advisory is appended below, with a detailed description of the vulnerability, and a review of the patch from Apple.

Security Advisory

A design flaw in MobileDevice.framework/Xcode and iOS/iPadOS/tvOS Development Tools allows an attacker in the same network to gain remote code execution on a target device.

Authors

Dany Lisiansky (@danyl931), Independent Security Researcher
Nikias Bassen (@pimskeks), Security Researcher and VP of Product Security, ZIMPERIUM zLabs

Mandatory Hash Tweet

@danyL931 on twitter

Additional Credits

Affected Components

macOS/Xcode MobileDevice.framework, IDEiOSSupportCore, DTDeviceKit(Base).framework, lldb-rpc-server
iOS/iPadOS/tvOS debugserver et al. / Development Tools (Developer Disk Image)

Affected Versions

macOS 10.12.4 through 10.15.6 / Xcode 9.0 through 11.7
iOS/iPadOS/tvOS 11.0 through iOS 13.7 running on latest hardware

Vendor

Apple, Inc.

CVEs

Disclosure Timeline

Vulnerability discovered: June 14, 2019
Vendor notified: March 12, 2020
Vendor asked to extend the disclosure period until “later this summer”: April 14, 2020
Vendor notified us the patches are present in the new beta versions and are planned to be published in a future security update: August 6, 2020
A downgrade attack bypassing the new patch was found, affecting iOS 13.6 and 13.7: August 14, 2020
Vendor explained only the upcoming iOS/iPadOS/tvOS 14 and watchOS 7 are fully addressed: September 5, 2020
Vulnerability patched: September 16, 2020

Summary

A design flaw in macOS’/Xcode’s MobileDevice.framework and the Development Tools for iOS/iPadOS/tvOS results in clear text communication over the network, despite the service connection setup performing an actual SSL handshake.

Impact

An attacker in a privileged network position may be able to gain arbitrary remote code execution that ultimately results in exfiltration of sensitive user data from the victim’s device.

Description

MobileDevice.framework on macOS encapsulates the (private) API required to start services on iOS/iPad/tvOS devices via lockdownd, the main service daemon running on those devices. It supports both USB and Wi-Fi connections (transparently, since this is actually handled through usbmuxd), and contains the protocol implementations for most of the services being used in host-device communications, like Apple File Conduit (AFC), Backup System (MobileBackup2), etc.

When a service is (successfully) started, the device’s lockdownd reports back to the host a port number the service has been made available on, and the property-list encapsulated dictionary also contains a key called EnableServiceSSL with a value of either True or False. Up to iOS 12.4.x, all services started via USB had it set to False, but all services started via Wi-Fi, or on a device with iOS/iPadOS/tvOS 13.x or higher via USB, will have this set to True. If True it tells the host, or more precisely the handling code in MobileDevice.framework, that the communication is supposed to be encrypted, so it performs an SSL Handshake, and the communication will normally be continued in ciphered form.

However, this is different for the services of the developer tools, like debugserver. The device-side implementation is provisioned by Xcode through a Developer Disk Image (DDI) once Xcode sees a device to make them available.

On the device side, lockdownd is handling the SSL handshake for all services that are started. Services are performing a “check-in” with lockdownd, allowing them to take over the connection. According to the service startup code, if the connection is via Wi-Fi, then EnableServiceSSL is always True; and a service does secure_lockdown_checkin, usually followed by lockdown_get_socket but also lockdown_get_securecontext so it can communicate securely. However in the debugserver case it never calls lockdown_get_securecontext so it does not even expect encrypted service communication in its current implementation.

The host-side implementations of the developer tool’s services are implemented outside of MobileDevice.framework. The debugserver service startup is done inside Xcode’s IDE plugin IDEiOSSupportCore in a method called -[DVTiOSDevice startDebugServerServiceForLaunchSession:] which will then call -[DTDKMobileDeviceToken startDebugServerServiceWithExtension:] (DTDeviceKitBase.framework) which – via a certain code path through other methods – calls out to AMDeviceSecureStartService in MobileDevice.framework, to request the service startup, and this will also perform the SSL Handshake. Back in IDEiOSSupportCore a “success” block will be called which then requests the socket file descriptor of the connection that has been established, using AMDServiceConnectionGetSocket. Finally Xcode will just pass this file descriptor as an argument to lldb-rpc-server:

/Applications/Xcode-beta.app/Contents/SharedFrameworks/LLDBRPC.framework/Resources/lldb-rpc-server –unix-fd 68 –fd-passing-socket 70

The code doesn’t check at all if SSL shall be used, but also the device-side implementation in debugserver does not even expect secure communication. As a result lldb-rpc-server communicates in plain text.

The same issue can be seen for the instruments service com.apple.instruments.remoteserver which is implemented in Library/PrivateFrameworks/DVTInstrumentsFoundation.framework/DTServiceHub on the developer disk image. In the same way as with debugserver, Xcode starts the service, the SSL handshake is performed, but then it continues communicating in plain text. On the device side it will, again, simply get the socket from lockdownd after check-in without considering the need for SSL against what the service startup suggested. More services might be affected but they haven’t been analyzed yet by the time of writing this advisory.

Important to note is that there is a MobileDevice.framework API which is also used at other places, for example for the crash report fetching service. This service uses AFC, and the host-side service implementation is also outside of MobileDevice.framework inside DTDeviceKitBase.framework. After getting the socket via AMDServiceConnectionGetSocket another call to AMDServiceConnectionGetSecureIOContext is performed, effectively allowing the process to use the SSL session that has been established.

However this is a different scenario: The full implementation is inside DTDeviceKitBase.framework, so it effectively runs in a single process after all. But in the debugserver case, the code is split across multiple processes; we have Xcode that – through the mentioned frameworks – requests the debugserver service startup, but will then spawn lldb-rpc-server that in turn is meant to communicate with the debugserver service on the remote device. Retrieving the ‘SecureIOContext’ is probably not feasible here due to the process boundary, but also lldb-rpc-server in its current implementation ‘only’ works with a file descriptor.

The Design Flaw

The problem is clearly visible now: this is an architectural design flaw. When MobileDevice.framework was created for the iPhone, there was initially no service that used SSL. This is also due to the fact that there was no Wi-Fi support for services in earlier iOS versions and security-wise no need for SSL for connections going over USB. When Xcode was created, or also for other external tools, it was no problem at all to just expose the file descriptor through an API for their usage. However, systems evolve, and so the day came on which “Wi-Fi sync” was created, where services were then forced to communicate in a ciphered way. This is when MobileDevice.framework was extended to perform the SSL handshake upon service startup (if the device requested it) and support SSL service connections.

A few years later with iOS 11, also Xcode (and iOS for that matter) received the capabilities of “Remote debugging” or “Remote development”, only that it looks like the code wasn’t adapted to reflect the SSL service requirement, which is both visible in the implementation of debugserver and the Xcode frameworks/lldb-rpc-server. This is why we see the SSL handshake (which is implemented inside MobileDevice.framework) on the service connection, but are then greeted with plain text communication.

Looking at the bigger picture here how the SSL support has been implemented and “external services” have been added the design flaw becomes visible: MobileDevice.framework handles the SSL handshake while you can still externally get the “raw” file descriptor that is directly connected to the service on the device.

This basically breaks the abstraction of the service communication code from the consumer application. Yes, as mentioned above, you can get the ‘SecureIOContext’ through AMDServiceConnectionGetSecureIOContext but this is not usable across processes. This design flaw made it possible/too easy to ‘create’ issues like the one described in this advisory, just by providing a way to break the service abstraction.

Proposed Solution

There are multiple ways this issue can be resolved. One way could be to provide an API that would return a service context that is externally usable and can be passed to AMDServiceConnectionSend, AMDServiceConnectionReceive, etc. (which actually can transparently handle connections with or without SSL context).

Another option would be to make sure the SSL context can be used from another process; this should be achievable via shared memory or XPC, with the design of an appropriate API for this.

Finally, it should also be possible to move the service startup code into lldb-rpc-server instead. This way there wouldn’t be a process boundary so there wouldn’t be a reason to bypass the service abstraction.

In any case lldb-rpc-server and also the device-side debugserver need to be updated to support encrypted communication as well.

The Patch

The vulnerability was fully patched with Xcode 12 and iOS/iPadOS/tvOS 14, and partially patched in iOS/iPadOS/tvOS 13.6 and 13.7 (see Downgrade attack).

The patch is contained within Xcode which provides updated Developer Disk Images that introduce new, secure variants of the affected lockdownd services.

On the host side, Xcode will now first try to connect to the secure variants (suffixed with DVTSecureSocketProxy). On success the connection will be routed through an in-process proxy which will make use of the SSL context to strip the encryption layer, and finally transmit the raw data to lldb-rpc-server.

On the device side, similar to the host, the secure services will internally proxy the secure connection to strip the encryption layer and expose the raw data to the component using it.

Downgrade Attack

Before the patch was publicly released, we were informed the following versions should contain the patch:

Xcode 12 beta 3+ Tools with iOS and iPadOS 13.6, macOS 10.15.6, tvOS 13.4.8, or watchOS 6.2.8
Xcode 12 beta 3+ Tools with iOS and iPadOS 14 beta 3+, macOS Big Sur 11 beta 3+, tvOS 14 beta 3+, or watchOS 7 beta 3+

After analyzing Xcode 12 beta 3 and Xcode 12 beta 4 to verify the supposed fix for our reported vulnerability, we noticed that the Developer Disk Images for iOS < 13.6 do not contain any mitigations at all. The 13.6 and 14.0 DDIs for Xcode 12 beta 3 do contain the new *.DVTSecureSocketProxy variants for the affected services; however, they also still provide the old, insecure variants. With Xcode 12 beta 4 (and up), the 14.0 DDI does not have the insecure variants anymore, while the 13.6 DDI still has them.

The issue with the current mitigation in Xcode is that it will fall back to the insecure service variant when the secure variant of the service cannot be started. As mentioned, with the 14.0 DDI of Xcode 12 beta 4 (and above), the insecure variants are not available anymore so the fallback mechanism cannot be abused to facilitate a “downgrade” attack in this case, but 13.6-13.7 DDI is still affected.

With packet inspection, a MITM-attacker could match the *.DVTSecureSocketProxy StartService packet (based on size or other heuristical data) that gets sent to lockdownd on the device. When the attacker then drops the connection on purpose, it will look to Xcode like the new secure variant is not available, and it will fall back to the insecure variant. This will result in the original vulnerability still being exploitable in those cases.

To prove that this “downgrade” attack is feasible, we came up with a simple PoC that will purposefully make the SSL connection fail as soon as lockdownd receives the StartService packet for the com.apple.debugserver.DVTSecureSocketProxy variant. By hooking SSLRead in lockdownd, scanning for the service string, and returning an error code, this will simulate the previously described scenario of a MITM-attacker dropping the connection. Xcode will then assume the service startup just failed and fall back to the insecure debugserver service (if it is available), and as a result you can still happily debug via Wi-Fi on a plaintext connection.

Proof of Concept

A Proof of Concept (POC) demonstrating the vulnerability with a debug session hijack, remote code execution, and sensitive data exfiltration can be found in this GitHub repository. Consult the README.md for further details.

c0ntextomy – Let’s Debug Together: CVE-2020-9992

Source

SEC v. Telegram: Part 3 — The extraterritorial reach of US securities laws

September 23, 2020 by bizbuildermike

As mentioned in the first and second parts of this story, on March 24, 2020, in a widely reported and closely followed decision, Judge Peter Castel imposed a sweeping preliminary injunction preventing Telegram from issuing its planned crypto asset, Grams. Shortly thereafter, the judge clarified his initial ruling by explicitly holding that the injunction applied to all sales worldwide regardless of where the original purchasers might be located. Efforts by Telegram to see that the Grams would not easily be resold into the United States were unavailing. This part of the story looks at the decision to apply U.S. requirements extraterritorially (outside our geographic borders, to a company headquartered elsewhere, selling to persons located elsewhere).

There is a clear presumption against applying U.S. law to foreign transactions. On the other hand, if the transaction has a sufficient connection to U.S. citizens or markets, U.S. law may be applied. The difficulty is in knowing how much of a connection is required.

In 2010, the U.S. Supreme Court held in Morrison v. National Australia Bank Ltd. that in order to apply the anti-fraud provisions of the U.S. securities laws, the securities in question either had to be listed on a domestic exchange or the transaction had to be domestic in character. Shortly after that decision was released, U.S. Congress enacted Dodd–Frank, which gave federal district courts jurisdiction over fraud claims involving significant steps in furtherance of a violation or having a foreseeable substantial effect in the United States.

The meaning of Dodd–Frank is subject to debate, with some commentators saying the language does not change the law and merely grants jurisdiction over claims. Others say the decision was designed to expand the reach of U.S. law. Given this uncertainty, in particular, it is not unreasonable for Judge Castel to have decided that if Telegram had issued the Grams, they would eventually have found their way into the hands of at least some U.S. purchasers. This could be seen as a substantial effect here. However, the fact that the judge’s ruling is defensible under U.S. law does not mean that the decision is supportable from a policy perspective.

By their very nature, crypto assets are inherently transnational. They cannot be confined to a single nation, and it is impossible to ascertain where they are definitively “located,” since in reality, a crypto asset is nothing more than computer-generated alpha-numeric sequences stored electronically on the World Wide Web. This means that when the U.S. insists on applying its law to crypto assets because they might be resold into the U.S., there is almost inevitably the risk of over-regulation.

In most cases, the issuer is likely to be complying with the law of the nation(s) where the primary effects are felt. Adding U.S. law on top of those is likely to create overlapping, redundant and potentially inconsistent requirements.

In addition, the possibility that U.S. law will be applied to transactions that are essentially occurring elsewhere creates uncertainty, making it more likely that entrepreneurs will work very hard to stay out of U.S. markets. Not only does this diminish the availability of capital for legitimate businesses but it also prevents U.S. investors from having the option of participating in those endeavors.

Not surprisingly, this reality is likely to increase international resentment. Just as the U.S. has its own objectives and interests to protect, so too do other nations. Their approach to regulation of securities transactions and markets reflects their own unique priorities and needs, while blanket application of U.S. law ignores their legitimate policy considerations. Foreign governments have repeatedly disapproved of U.S. efforts to enforce anti-fraud mandates in their markets; they are no more likely to welcome our regulations in their crypto markets.

In the past, international reaction has suggested that the extraterritorial application of U.S. law is intrusive and arrogant. This, in turn, increases the impetus for pushback where other nations seek to impose their laws and vision on U.S. businesses.

The reality is that a system of international regulation where individual nations vie to have their particular viewpoint applied globally is antithetical to the goal of harmonization. Extraterritorial application of U.S. domestic law diminishes the role of traditional international law, resulting not only in confusion, over-regulation and legal uncertainty but also reducing the possibility of developing an international consensus where a harmonized, cooperative approach to regulation of crypto is created.

SEC v. Telegram is a single decision, from a single judge, in a single court, on a motion for a preliminary injunction. There are many opportunities for the decision’s impact to be limited. It can be factually distinguished because Telegram did not raise many of its arguments until after the preliminary injunction issued. Other courts can disagree with the rationale or result. The SEC could change its approach in future enforcement proceedings. Congress could step in to mandate a different approach.

This comment suggests that any of those alternatives are likely to be preferable to insisting U.S. law must apply to all crypto transactions no matter where they are based on the grounds that the crypto assets are likely to land in the hands of U.S. purchasers eventually.

This is Part 3 of a three-part series on the legal case between the U.S. SEC and Telegram’s claims to be securities. Read Part 1 on introduction to the context here, and Part 2 on why this decision should not be followed in other cases here.

The views, thoughts and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.

Carol Goforth is a university professor and the Clayton N. Little Professor of Law at the University of Arkansas (Fayetteville) School of Law.

The opinions expressed are the author’s alone and do not necessarily reflect the views of the University or its affiliates. This article is for general information purposes and is not intended to be and should not be taken as legal advice.

SEC v. Telegram: Part 3 — The extraterritorial reach of US securities laws

Source