Note: CHANGELOG is an occasional feature letting you know about changes to various CALI websites. It is mostly technical in nature but may include initial listing of new features and resources. Updates to www.cali.org added database tracking of downloads to CALI bookstore updated AutoPublish to set default state of new resources to published modified AutoPublish to […]
Original URL: http://spotlight.classcaster.net/2017/08/23/changelog-8232017/
Microsoft says it has formed a new 5,000-person engineering and research team to focus on its artificial intelligence products — a major reshaping of the company’s internal structure reminiscent of its massive pivot to pursue the opportunity of the Internet in the mid-1990s.
NoScript, Firebug, and other popular Firefox add-on extensions are opening millions of end users to a new type of attack that can surreptitiously execute malicious code and steal sensitive data, a team of researchers reported.
The attack is made possible by a lack of isolation in Firefox among various add-ons installed by an end user. The underlying weakness has been described as an extension reuse vulnerability because it allows an attacker-developed add-on to conceal its malicious behavior by invoking the capabilities of other add-ons. Instead of directly causing a computer to visit a booby-trapped website or download malicious files, the add-on exploits vulnerabilities in popular third-party add-ons that allow the same nefarious actions to be carried out. Nine of the top 10 most popular Firefox add-ons contain exploitable vulnerabilities. By piggybacking off the capabilities of trusted third-party add-ons, the malicious add-on faces much better odds of not being detected.
“These vulnerabilities allow a seemingly innocuous extension to reuse security-critical functionality provided by other legitimate, benign extensions to stealthily launch confused deputy-style attacks,” the researchers wrote in a paper that was presented last week at the Black Hat security conference in Singapore. “Malicious extensions that utilize this technique would be significantly more difficult to detect by current static or dynamic analysis techniques, or extension vetting procedures.”
Of the top 10 most popular add-ons vetted by Mozilla officials and made available on the Mozilla website, only Adblock Plus was found to contain no flaws that could be exploited by a malicious add-on that relied on reuse vulnerabilities. Besides NoScript, Video DownloadHelper, Firebug, Greasemonkey, and FlashGot Mass Down all contained bugs that made it possible for the malicious add-on to execute malicious code. Many of those apps, and many others analyzed in the study, also made it possible to steal browser cookies, control or access a computer’s file system, or to open webpages to sites of an attacker’s choosing.
The researchers noted that attackers must clear several hurdles for their malicious add-on to succeed. First, someone must go through the trouble of installing the trojanized extension. Second, the computer that downloads it must have enough vulnerable third-party add-ons installed to achieve the attackers’ objective. Still, the abundance of vulnerable add-ons makes the odds favor attackers, at least in many scenarios.
In many cases, a single add-on contains all the functionality an attacker add-on needs to cause a computer to open a malicious website. In other cases, the attacker add-on could exploit one third-party add-on to download a malicious file and exploit a second third-party add-on to execute it. In the event that a targeted computer isn’t running any third-party add-ons that can be exploited, the attacker-developed add-on can be programmed to provide what’s known as a “soft fail” so that the end user has no way of detected an attempted exploit. Here’s a diagram showing how the new class of attack works.
“We note that while it is possible to combine multiple extension-reuse vulnerabilities in this way to craft complex attacks, it is often sufficient to use a single vulnerability to successfully launch damaging attacks, making this attack practical even when a very small number of extensions are installed on a system,” the researchers wrote. “For example, an attacker can simply redirect a user that visits a certain URL to a phishing website or automatically load a web page containing a drive-by-download exploit.”
The researchers said they developed an add-on containing about 50 lines of code that passed both Mozilla’s automated analysis and its full review process. Ostensibly, ValidateThisWebsite—as the add-on was called—analyzed the HTML code of a given website to determine if it was compliant with current standards. Behind the scenes, the add-on made a cross-extension call to NoScript that caused Firefox to open a Web address of the researchers’ choosing.
In an e-mail, Firefox’s vice president of product issued the following statement:
The way add-ons are implemented in Firefox today allows for the scenario hypothesized and presented at Black Hat Asia. The method described relies on a popular add-on that is vulnerable to be installed, and then for the add-on that takes advantage of that vulnerability to also be installed.
Because risks such as this one exist, we are evolving both our core product and our extensions platform to build in greater security. The new set of browser extension APIs that make up WebExtensions, which are available in Firefox today, are inherently more secure than traditional add-ons, and are not vulnerable to the particular attack outlined in the presentation at Black Hat Asia. As part of our electrolysis initiative—our project to introduce multi-process architecture to Firefox later this year—we will start to sandbox Firefox extensions so that they cannot share code.
In the meantime, the researchers said Firefox users would benefit from improvements made to the screening process designed to detect malicious add-ons when they’re submitted. To that end, they have developed an application they called CrossFire that automates the process of finding cross-extension vulnerabilities. In their paper, they proposed that it or a similar app be incorporated into the screening process.
“Naturally, we do not intend our work to be interpreted as an attack on the efforts of Firefox’s cadre of extension vetters, who have an important and difficult job,” the researchers wrote. “However, since the vetting process is the fundamental defense against malicious extensions in the Firefox ecosystem, we believe it is imperative that (i) extension vetters be made aware of the dangers posed by extension-reuse vulnerabilities, and that (ii) tool support be made available to vetters to supplement the manual analyses and testing they perform.”
Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/ltuoUECFaAw/
How to achieve a full reflected XSS attack which includes the ability to run a complete script and not just an alert popup with the least amount of characters? Some people already tried to answer this question like in here and here.
As we may imagine it’s possible to have an URL parameter echoed in a source of a script:
which would make possible to launch a full XSS attack providing a source with a short domain like //14.rs (7 chars length). A variation decreases the injection to just 5 chars if double slashes are already in native code:
However, both scenarios are very unlikely.
It uses the 0.0.0.0 IP address as the href of the anchor for demo purposes, so we can try it locally. In a real vulnerable page it would need to be a valid yet expired domain (broken link) able to be acquired, spoofed or even compromised. Of course, this alone isn’t enough to exploit the page which would invalidate our next step.
Which just inserts a <base tag before the <a one to hijack its href attribute (the acquired/spoofed domain). This sets the base URL of the document to something we control and then we just need a script in the page being called from a relative URL, which is not that difficult to find into a given page.
Now setting a web server or just a listener on port 80 to deliver our script is enough to pop the alert (or anything we want):
An useful dead link with the right conditions is really hard to find, but to deal with the alignment involving the injection and the anchor, the trick used here and probably some browser quirks may help.
Anyway, in the cases where only the 2nd condition (script from relative URL) is met, we can still use the <base tag but this time providing the href:
Which is a full XSS vector with IP in decimal for a local PoC with just 15 chars.
Typora is a minimalist markdown editor for Windows and Mac. Markdown is a simple language which uses plain text formatting to create rich text documents, but you don’t need to understand any of that to get started. Typora opens much like any other editor. Start typing and you can style text, copy and paste, find and replace, undo, open, print, save and more, with all the keyboard shortcuts you know already. Right-clicking displays a context menu with options to insert links, quotes, unordered/ ordered/ task lists, paragraphs, headings, images and more. Use this for a while and you begin to… [Continue Reading]
Original URL: http://feeds.betanews.com/~r/bn/~3/Z8qii8wPQuM/
AWS Is currently having issues with a bunch of our instances and the console reports the following error
“An error occurred fetching instance data: The service is unavailable. Please try again shortly.
“Anyone else experiencing a problem?
For more than a month, users of the remote login service TeamViewer have taken to Internet forums to report their computers have been ransacked by attackers who somehow gained access to their accounts. In many of the cases, the online burglars reportedly drained PayPal or bank accounts. No one outside of TeamViewer knows precisely how many accounts have been hacked, but there’s no denying the breaches are widespread.
Over the past three days, both Reddit and Twitter have exploded with such reports, often with the unsupported claim that the intrusions are the result of a hack on TeamViewer’s network. Late on Friday afternoon, an IBM security researcher became the latest to report a TeamViewer account takeover.
“In the middle of my gaming session, I lose control of my mouse and the TeamViewer window pops up in the bottom right corner of my screen,” wrote Nick Bradley, a practice leader inside IBM’s Threat Research Group. “As soon as I realize what is happening, I kill the application. Then it dawns on me: I have other machines running TeamViewer!”
I run downstairs where another computer is still up and running. Lo and behold, the TeamViewer window shows up. Before I am able to kill it, the attacker opens a browser window and attempts to go to a new web page. As soon as I reach the machine, I revoke control and close the app. I immediately go to the TeamViewer website and change my password while also enabling two-factor authentication.
Lucky for me, those were the only two machines that were still powered on with TeamViewer installed. Also lucky for me is the fact that I was there when it occurred. Had I not been there to thwart the attack, who knows what would have been accomplished. Instead of discussing how I almost got hacked, I’d be talking about the serious implications of my personal data leak.
Bradley’s account came a few hours after Germany-based TeamViewer reaffirmed what it has steadfastly maintained for the past two weeks—that the account takeovers are the result of end users’ careless passwords practices. In a statement, company officials alluded to the recent cluster of “megabreaches” that have dumped more than 642 million passwords into the public domain over the past month. The officials wrote:
As you have probably heard, there have been unprecedented large scale data thefts on popular social media platforms and other web service providers. Unfortunately, credentials stolen in these external breaches have been used to access TeamViewer accounts, as well as other services.
We are appalled by the behaviour of cyber criminals and are disgusted by their actions towards TeamViewer users. They have taken advantage of common use of the same account information across multiple services to cause damage.
The statement went on to announce two measures being introduced in response to the large number of reported TeamViewer hijackings. The first, dubbed “Trusted Devices,” ensures that before a device can access an existing TeamViewer account for the first time, the account holder must explicitly confirm that the new device is trusted. TeamViewer is implementing the measure using an in-app notification that asks account holders to approve the device by clicking a link sent through e-mail.
The second measure, called “Data Integrity,” provides automated monitoring that detects when an account has been hacked.
“The system determines continuously if your TeamViewer account shows unusual behavior (e.g. access from a new location) that might suggest it has been compromised,” Friday’s statement explained. “To safeguard your data integrity, your TeamViewer account will be marked for an enforced password reset.”
TeamViewer spokesman Axel Schmidt told Ars that TeamViewer officials initially planned to introduce these security features later this year. The growing number of public posts reporting TeamViewer account takeovers prompted the early roll out, he said.
The account provided by Bradley, the IBM security researcher, is consistent with TeamViewer’s position that the takeovers are the result of compromised passwords. Bradley said he had forgotten he had the remote login software installed on his computers, and the compromise was “most likely due to me not changing my leaked password.”
Not that TeamViewer’s public response has been much better. Representatives often go days or weeks without issuing any sort of statement, even though it’s clear that a significant number of users—likely in the hundreds or thousands—are being hit by attacks that expose their most sensitive data. When company officials do respond, they issue terse press releases that omit important details. TeamViewer, for instance, has yet to address reports that some of the attacks have successfully bypassed its two-factor authentication protection, or that the attacks worked against accounts protected with strong passwords.
TeamViewer’s claim that the surge in attacks is tied to the massive number of passwords that recently entered the public domain is plausible, but it’s likely not the only contributing factor. It wouldn’t be surprising if weaknesses in TeamViewer software are also involved. One possibility: a login mechanism that allows attackers to try large numbers of passwords without being locked out. Another: a flaw that allows attackers to circumvent two-factor protections. To date, TeamViewer’s public statements leave users with a sense the company isn’t providing a thorough accounting of what it knows, and that in turn gives way to mistrust and conspiracy theories.
Ars is calling on end users and network administrators who have been hit by this attack to provide log files in the hours leading up to the compromise. We’ll show those files to researchers who will attempt to pinpoint common causes. Readers can submit their logs by emailing me at the the address found here.
In the meantime, TeamViewer users should ensure their accounts are protected with a randomly generated password that’s at least 10 characters long, contains numbers, symbols, and upper- and lower-case letters, and is unique. It’s also a good idea to run TeamViewer only when it’s truly needed, rather than allowing it to autostart each time a computer is turned on. How-To Geek has a thorough guide on locking down TeamViewer here.
TeamViewer engineers certainly have the ability to perform log analyses, presumably at a much more granular level than any outsiders can. But there’s more to these compromises than what TeamViewer has said to date, and it’s time we all learned what it is.