Even as the other FAANG stocks slumped, the trillion-dollar electronics company has continually satisfied Wall Street with quarter-over-quarter revenue growth. But will Apple’s momentum continue after it reports its fourth-quarter earnings on Thursday?
The consensus, so far, is yes. Apple is expected to post revenue of $61.43 billion (earnings per share of $2.78), an increase of 17 percent year-over-year and GAAP EPS of $2.78, according to analysts polled by FactSet. Investors will be paying close attention to iPhone unit sales, which account for the majority of Apple’s revenue, as well as Mac sales, which accounted for roughly 10 percent of the company’s revenue in Q3.
The company reported its Q3 earnings on July 31, posting $53.3 billion in revenue, its best June quarter ever and fourth consecutive quarter of double-digit revenue growth, the company said.
At today’s hardware event in Brooklyn, Apple’s chief executive officer Tim Cook shared that the company’s Mac business had grown to 100 million monthly active users — a big accomplishment for the nearly 10-year-old product. Cook also showcased the new MacBook Air and introduced the new iPad Pro and Mac Mini.
Not even Lana Del Rey’s surprise performance at the event was enough to rile up Wall Street. Apple’s stock was unreactive today, as is typically the case with hardware spectacles like these. Apple ultimately closed up about .5 percent. That’s a better outcome than its last hardware event in September, which despite the highly anticipated announcements of the iPhone XS and Apple Watch Series 4, forced the company’s stock down about 1.2 percent on the news.
Apple’s stock performance year to date
Year to date, Apple’s stock has risen more than 30 percent from a February low of $155 per share to an October high of $229.
If it fails to meet analyst expectations on Thursday, it’s bad news for the stock market: “Apple is the last domino standing,” Market Watch wrote earlier today. “Its FAANG brethren have all crashed, even the mighty Amazon, which has slumped about 25% from all-time highs.”
If you missed today’s event, we live-blogged the whole thing here and detailed all the new hardware here.
Apple’s low-end, 21.5-inch iMac appears to be in short supply at Apple Stores and in Apple’s online storefront in the United States. The shortage could be a hint of an imminent change to the iMac lineup just a few days before Apple hosts a product launch event on April 20.
In particular, the cheapest, 1080p iMac (the rest of the 21.5-inch models have 4K displays) is seeing ship dates slipping back several days into late April or early May, which is usually a sign of low supply. This Mac in particular is also increasingly unavailable for pickup at physical Apple Stores around the US.
Meanwhile, the more expensive 27-inch iMac is shipping within a normal window, and it is showing as available at more retail stores.
This development comes a few weeks after Apple discontinued several certain configurations of the 21.5-inch iMac—specifically, those with 512GB of 1TB SSD storage options. You can currently buy 21.5-inch iMacs with 256GB of solid-state storage, or a 1TB configuration that combines an SSD with an older hard drive.
Historically, changes like these have often been signs of imminent new product launches or discontinuations. But there is one wrinkle that makes that less of a sure thing this time: a worldwide chip shortage that may impact Apple’s products. The shortage has impacted many other tech and gadget companies already, and it may be the cause here, too.
M1 first, M1X later?
We’re speculating here, but the fact that only the lower-end models are seeing significant shortages while the 27-inch iMac is business as usual seems like a promising sign for an imminent product launch.
As we explained in our article on what to expect from Apple’s upcoming event, Apple is most likely to upgrade a low-end iMac before it addresses the faster, more expensive configurations.
An entry-level iMac would probably feature Apple’s M1 chip, the same seen in other low-end Macs late last year, while a higher-end model would need a new chip that Apple has not yet introduced, such as an “M1X.”
This split could explain why some leaks and rumors have said an iMac update is coming next week, while others say it will be later in the year. But again, today’s news could be the result of chip shortages rather than a change in Apple’s product lineup.
In any case, we’ll find out one way or another when Apple holds its event on Tuesday next week.
A publicly available software development tool contained malicious code that stole the authentication credentials that apps need to access sensitive resources. It’s the latest revelation of a supply chain attack that has the potential to backdoor the networks of countless organizations.
The Codecov bash uploader contained the backdoor from late January to the beginning of April, developers of the tool said on Thursday. The backdoor caused developer computers to send secret authentication tokens and other sensitive data to a remote site controlled by the hackers. The uploader works with development platforms including Github Actions, CircleCI, and Bitrise Step, all of which support having such secret authentication tokens in the development environment.
A pile of AWS and other cloud credentials
The Codecov bash uploader performs what is known as code coverage for large-scale software development projects. It allows developers to send coverage reports that, among other things, determine how much of a codebase has been tested by internal test scripts. Some development projects integrate Codecov and similar third-party services into their platforms, where there is free access to sensitive credentials that can be used to steal or modify source code.
Code similar to this single line first appeared on January 31:
The code sends both the GitHub repository location and the entire process environment to the remote site, which has been redacted because Codecov says it’s part of an ongoing federal investigation. These types of environments typically store tokens, credentials, and other secrets for software in Amazon Web Services or GitHub.
Armed with these secrets, there’s no shortage of malicious things an attacker could do to development environments that relied on the tool, said HD Moore, a security expert and the CEO of network discovery platform Rumble.
“It really depends on what was in the environment, but from the point that attackers had access (via the bash uploader), they might have been able to plant backdoors on the systems where it ran,” he wrote in a direct message with Ars. “For GitHub/CircleCI, this would have mostly exposed source code and credentials.”
The attackers likely ended up with a pile of AWS and other cloud credentials in addition to tokens that could give them access to private repositories, which includes source code, but also all the other stuff that the token was authorized for. On the extreme end, these credentials would be self-perpetuating—the attackers use a stolen GitHub token to backdoor the source code, which then steals downstream customer data, etc. The same could apply to AWS and other cloud credentials. If the credentials allowed for it, they could enable infrastructure takeover, database access, file access, etc.
In Thursday’s advisory, Codecov said the malicious version of the bash uploader could access:
Any credentials, tokens, or keys that our customers were passing through their CI runner that would be accessible when the bash uploader script was executed
Any services, datastores, and application code that could be accessed with these credentials, tokens, or keys
The git remote information (URL of the origin repository) of repositories using the bash uploaders to upload coverage to Codecov in CI
“Based upon the forensic investigation results to date, it appears that there was periodic unauthorized access to a Google Cloud Storage (GCS) key beginning January 31, 2021, which allowed a malicious third-party to alter a version of our bash uploader script to potentially export information subject to continuous integration (CI) to a third-party server,” Codecov said. “Codecov secured and remediated the script April 1, 2021.”
The Codecov advisory said that a bug in Codecov’s Docker image-creation process allowed the hacker to extract the credential required to modify the bash uploader script.
The tampering was discovered on April 1 by a customer who noticed that the shasum that acts as a digital fingerprint to confirm the integrity of bash uploader didn’t match the shasum for the version downloaded from https://codecov.io/bash. The customer contacted Codecov, and the tool maker pulled the malicious version and started an investigation.
Codecov is urging anyone who used the bash updater during the affected period to revoke all credentials, tokens, or keys located in CI processes and create new ones. Developers can determine what keys and tokens are stored in a CI environment by running the env command in the CI Pipeline. Anything sensitive should be considered compromised.
Additionally, anyone who uses a locally stored version of the bash uploader should check it for the following:
Curl -sm 0.5 -d “$(git remote -v)
If these commands appear anywhere in a locally stored bash uploader, users should immediately replace it with the most recent version from https://codecov.io.bash.
Codecov said that developers using a self-hosted version of bash update are unlikely to be affected. “To be impacted, your CI pipeline would need to be fetching the bash uploader from https://codecov.io/bash instead of from your self-hosted Codecov installation. You can verify from where you are fetching the bash uploader by looking at your CI pipeline configuration,” the company said.
The appeal of supply chain attacks
The compromise of Codecov’s software development and distribution system is the latest supply chain attack to come to light. In December, a similar compromise hit SolarWinds, the Austin, Texas maker of network management tools used by about 300,000 organizations around the world, including Fortune 500 companies and government agencies.
The hackers who carried out the breach then distributed a backdoored update that was downloaded by about 18,000 customers. About 10 US federal agencies and 100 private companies eventually received follow-on payloads that sent sensitive information to attacker-controlled servers. FireEye, Microsoft, Mimecast, and Malwarebytes were all swept up in the campaign.
More recently, hackers carried out a software supply chain attack that was used to install surveillance malware on the computers of people using NoxPlayer, a software package that emulates the Android operating system on PCs and Macs, mainly so users can play mobile games on those platforms. A backdoored version of NoxPlayer was available for five months, researchers from ESET said.
The appeal of supply chain attacks to hackers is their breadth and effectiveness. By compromising a single player high in the software supply, hackers can potentially infect any person or organization who uses the compromised product. Another feature that hackers find beneficial: there’s often little or nothing targets can do to detect malicious software distributed this way because digital signatures will indicate that it’s legitimate.
In the case of the backdoored bash update version, however, it would have been easy for Codecov or any of its customers to detect the malice by doing nothing more than checking the shasum. The ability for the malicious version to escape notice for three months indicates that no one bothered to perform this simple check.
People who have used the bash updater between January 31 and April 1 should carefully inspect their development builds for signs of compromise by following the steps outlined in Thursday’s advisory.
The Australian Competition & Consumer Commission (ACCC) has ruled that Google misled Android users over its collection of location data. This ruling is in reference to the “Location History” controversy from a few years ago. The Associated Press reported at the time that turning off the Location History setting does not disable all location-tracking features across every Google product.
The ACCC’s press release states that from January 2017 to December 2018 (the AP article was published in August 2018), “Google misrepresented that the ‘Location History’ setting was the only Google Account setting that affected whether Google collected, kept or used personally identifiable data about their location.” The ruling continues, saying, “In fact, another Google Account setting titled ‘Web & App Activity’ also enabled Google to collect, store and use personally identifiable location data when it was turned on, and that setting was turned on by default.”
With the ACCC’s finding of wrongdoing, it’s not clear what the Australian government plans to do about the situation yet. The press release says, “The ACCC is seeking declarations, pecuniary penalties, publications orders, and compliance orders. This will be determined at a later date.” ACCC Chair Rod Sims added, “In addition to penalties, we are seeking an order for Google to publish a notice to Australian consumers to better explain Google’s location data settings in the future. This will ensure that consumers can make informed choices about whether certain Google settings that… collect location data should be enabled.”
Location History used to only affect data collected through Google Maps. This made sense back in 2012, when Location History started out as a setting inside the Google Maps app. Google’s push for unified privacy settings, as seen in the “My Account” page in 2015, meant that all of these settings were pulled into a single page, and “Location History” lost the Google Maps context it used to have. In 2018, the AP asked, “Why does this setting in my account called ‘Location History’ not turn off location tracking for my entire account?” and a big controversy ensued.
Google changed the Location History settings after the AP’s article, and today the company says the feature is “a Google Account–level setting that saves where you go with every mobile device.” Note that this concerns mobile devices only, and a lot of location data still lives under the “Web and App Activity” setting, which Google vaguely says covers some location data “on Google sites, apps, and services.” As this support article explains, the other two Google location settings you might want to track down are Google Maps location sharing, which is for sharing your location with your friends, and Android’s Google Location Accuracy, (AKA Google Play Service’s Fused Location Provider), which tries to compute a low-power location from Wi-Fi and cellular data without having to fire up the expensive GPS receiver. Google does not do anything in a unified, company-wide fashion, and privacy settings are no exception.
Google’s privacy settings are so vague and confusing that even Google’s own employees don’t understand them, and the settings have already been the subject of at least one lawsuit.