17 C
Monday, September 25, 2017
Home Tags The Catch

Tag: The Catch

TypeScript 2.5, the upcoming upgrade to Microsoftrsquo;s popular typed superset of JavaScript, is now available as a release candidate.
It includes an enhancement for try/catch statements for errors as well as compiler improvements.The catch binding parameters capability in TypeScript 2.5 uses a late-stage ECMAScript feature to make catch binding optional in try/catch statements. Making catch binding optional “means we can just omitnbsp;unusedErrornbsp;altogether,” said Daniel Rosenwasser, Microsoftrsquo;s program manager for TypeScript.

The reason for that is there are times when developers expect something might fail by throwing an error, but the developer does not care what the error is.To read this article in full or to leave a comment, please click here
Bluetooth signals from cars provide an accurate record of real-time traffic patterns.
With every innovation comes new complications.

Containers made it possible to package and run applications in a convenient, portable form factor, but managing containers at scale is challenging to say the least.Kubernetes, the product of work done internally at Google to solve that problem, provides a single framework for managing how containers are run across a whole cluster.

The services it provides are generally lumped together under the catch-all term “orchestration,” but that covers a lot of territory: scheduling containers, service discovery between containers, load balancing across systems, rolling updates/rollbacks, high availability, and more.To read this article in full or to leave a comment, please click here
Video analysis at Digital Foundry confirms how Square Enix screwed this one up.
Details have been released on a simple Office 365 hack that incorrectly identifies spoofed emails pretending to be from the Microsoft.com domain as valid.

The vulnerability being targeted was privately disclosed by Turkish security researcher Utku Sen, and was patched by Microsoft this month. According to Sen, the vulnerability took advantage a flaw in Microsoft’s DKIM (DomainKeys Identified Mail) validator used in Outlook 365, part of Microsoft’s Office 365 Web Services suite.

Exploiting this weakness, a hacker could use email forwarding tools in Outlook 365 to validate phishing emails that spoofed the Microsoft.com domain.

The technique could give bogus emails the appearance of legitimacy and avoid the messages from getting caught in a recipient’s spam filter. Sen, an application security engineer based in Turkey, said the vulnerability is particularly problematic when used in conjunction with the popular Russian email service from Yandex.

That’s because Yandex email recipients who were on the receiving end of the spoofed emails in question, also received green “check” certificates, below, that indicated the emails were authenticated and could be trusted.

That green certificate, according to Yandex, indicated: “With a DKIM signature, the email recipient can verify that the message really came from the supposed sender.” Microsoft and Yandex, considered the Google of Russia, addressed the vulnerability earlier this month. In Sen’s tests, he used the email phishing tool called SEES (Social Engineering Email Sender).
SEES allows you to craft emails with bogus email sender-field data that could be anything, such as MickeyMouse[@]Disney.com, SatyaNadella[@]Microsoft.com or AccountServices[@]Microsoft.com.

The catch is, most email services such as Yandex, Google and Yahoo normally catch these types of crafted phishing emails sent from tools such as SEES and send them straight to a spam folder. However, when Sen configured his Outlook 365 web client to automatically forward spoofed emails to Google, Yandex or any email address, the spoofed email were identified as valid. Sen theorizes that the culprit was the Microsoft signing domain (onmicrosoft.com) that his Outlook 365 client was using. He believes that typically emails that spoof sender data are sent straight to a recipient’s spam filter because emails lack a valid signature and can’t be authenticated.

The problem was tied to the way Outlook 365 was handling forwarded email when the spoofed domain was Microsoft[.]com. Outlook 365 automatically validated those spoofed messages and tricked spam filters into thinking emails were legit. Since Sen posted a technical explanation of the vulnerability, he updated his analysis with a plausible explanation from a Reddit user who agreed Microsoft’s DKIM validation process was to blame. “Because Outlook was blindly signing these messages it was redirecting, if the message had a fake from field saying something@microsoft.com, then after Outlook blindly redirected it, it’d have a genuine DKIM signature from Microsoft by coincidence, even though the original email wasn’t from Microsoft at all,” Sen said. When Sen tried the same technique using email forwarding features in Gmail or Yandex the vulnerability wasn’t present.
In Sen’s tests, the vulnerability only worked when used through Outlook 365. Sen said he identified that problem in September, and by late October Microsoft informed him the vulnerability was fixed.

Earlier this month, Microsoft Security Response Center credited Sen for finding the vulnerability. Yandex has since stopped supporting the green DKIM verification certificate shown on “validated” emails, according to Sen.
In early August we detected several cases of a banking Trojan being downloaded automatically when users viewed certain news sites on their Android devices. Later it became apparent that this was being caused by advertising messages from the Google AdSense network, and was not restricted to news sites. In fact, any site using AdSense to display adverts could potentially have displayed messages that downloaded the dangerous Trojan-Banker.AndroidOS.Svpeng and automatically saved it to the device’s SD card. This behavior surprised us: typically, the browser warns users about downloading a potentially dangerous file, and offers them a choice of whether or not to save the file. We intercepted traffic coming from the attacked device when this sort of “advert” was displayed, and figured out how the malicious program was downloaded and automatically saved. Some statistics First of all, let’s provide some information about the latest versions of Trojan-Banker.AndroidOS.Svpeng. It is limited to Russia and the CIS (more about this later). Below is a graph showing detections of the Trojan’s latest version – Svpeng.q. And here is the graph for the previous version that was distributed in July 2016, also via AdSense: As you can see from the graphs, within a two-month period Svpeng was detected on the computers of approximately 318,000 users, with the detection rate peaking at around 37,000 attacked users in one day. The high rates and abrupt changes in the number of detections are easy to explain: Google has been quick to block the ads that the Trojan uses for propagation. However, this is a reactive rather than a proactive approach – the malicious ads were blocked after the Trojan was already on thousands of Android devices. It is also worth noting that there were multiple occasions in the past two months when these ads found their way on to AdSense; similar attacks have been occurring up to the present time, with the most recent attack registered on 12 September 2016. Now for the juicy part Let’s look at how the displaying of an ad is related to the automatic download of the APK file containing the Trojan and it being saved to the SD card. Below is the HTTP request that leads to the cybercriminals’ advert being displayed: In response to this request, the server sends a Javascript script that displays the ad message. However, this script contains a hidden surprise: at the beginning there is some heavily obfuscated code. Let’s look, step by step, at what this code actually does: Declares the variables necessary for operation and deciphers the payload: We can see that the APK file was downloaded in the form of an encrypted array of bytes in the script. Now it just needs to be saved to the SD card. Defines the function that will save the file. The code checks the availability of functions from various browser engines, and if they are unavailable, defines its own function. The object URL and the element <a> (the latter being an HTML notation for a link) are created in this function. The resulting link is assigned the attribute ‘href’ (where the link leads to), and the malicious program emulates a click on this link. This method is not new; quite possibly the Trojan’s creators borrowed it from here, and only added obfuscation and a restriction: the click simulation is only done on touchscreen devices, which for the most part are smartphones. Breaks the decrypted APK file into blocks of 1024 bytes. Sets the handler for a page load event. Handler activation initiates the automatic saving of the APK file to the SD card. Apart from the extra checks to see if the script runs on the smartphone or not, there is an important check in the code to identify the language used on the device. The attackers only target smartphones with a Russian-language interface – these are typically devices belonging to users in Russia and, to a lesser degree, CIS states. Where’s the catch? The method described above only works in Google Chrome for Android. When an APK file is downloaded via a link leading to an external web resource, the browser displays a warning that a potentially dangerous object is being downloaded, and prompts the user to choose whether or not to save the file. When an APK file is broken down into pieces and handed over to the save function via Blob() class, there is no check for the type of the content being saved, so the browser saves the APK file without notifying the user. We notified Google about this browser behavior and that it was being exploited to distribute malicious content. At the time of publishing a patch had been released that fixed this problem in Google Chrome and will become available to users the next time the browser is updated. In all other browsers, this method either does not work, or the user is asked if they want to save the file or not. Kaspersky Lab recommends updating Google Chrome to prevent infection by the malware when viewing sites that use AdSense. Conclusion Of course, just downloading the Trojan is not enough for it to work; the user also has to install it. To ensure this, the attackers resort to social engineering. The Trojan may be downloaded with any of the following names: last-browser-update.apk WhatsApp.apk Google_Play.apk 2GIS.apk Viber.apk DrugVokrug.apk Instagram.apk VKontakte.apk minecraftPE.apk Skype.apk Android_3D_Accelerate.apk. SpeedBoosterAndr6.0.apk new-android-browser.apk AndroidHDSpeedUp.apk Android_update_6.apk WEB-HD-VIDEO-Player.apk Asphalt_7_Heat.apk CHEAT.apk Root_Uninstaller.apk Mobogenie.apk Chrome_update.apk Trial_Xtreme.apk Cut_the_Rope_2.apk Установка.apk Temple_Run.apk These names imitate the names of popular legitimate apps or try to convince users that the downloaded app is important and has to be installed. In the latest versions of Android, installation of apps downloaded from unknown sources is blocked by default, but the cybercriminals are obviously counting on users disabling this setting to install an “important browser update” or a newer version of a popular app that is already on their phone. So far, those behind Svpeng have limited their attacks to smartphone users in Russia. However, next time they push their “adverts” on AdSense they may well choose to attack users in other countries; we have seen similar cases in the past. After all, what could be more convenient than exploiting the most popular advertising platform to download their malicious creations to hundreds of thousands of mobile devices?
I recently started a new job, which I love. However, since I’m working for a San Francisco startup, of course my work computer is a MacBook Pro. Most people would be very happy about that.

But I’ve been using Linux as my primary desktop platform since, like, 2008, so a Mac is an adjustment for me.

There are worse possibilities -- at least I don’t have to deal with Outlook or Windows.

Also, there are plenty of people to help me with this painful transition. My ripe relationship with Apple I've had Macs in the past. When I worked for another startup, JBoss, I was the sole PowerBook person. At the time, in the dark ages of the early part of this millennium, I was traveling around the world giving presentations. Most of humanity, having freshly crawled out of caves, used those awful video projectors instead of big-screen TVs.

At the time the PowerBook connected to more of those items than Windows did. (You don’t want to know what you had to do for Linux’s X Windows to connect.) Yet far from being one of the contented masses, I always had Apple-specific issues.

The company decided to hold all Java developers hostage for an OS upgrade right when I needed the new JDK most.

The power coupling used to rip out of the motherboard because it was near a modem, which created a weak point in the case. Later Apple moved the weak point to the CD drive, which was under my wrist while typing, so the drive would jam. Then there were the batteries that swelled up and broke the keyboard.

There were screens that had lots of dead pixels and bright spots that annoyed me, not to mention the power cord that kept shorting out, which had to be replaced for $85. Apple’s response each time was that it was somehow my fault.

Eventually, I’d end up buying a new laptop -- before the bad press would make Apple fix the flaw for the more patient people. My annoyance grew.

Finally, the last straw: That infernal “beg for attention” format of the Apple Store and the “pay to not stand around all day when the hardware is borked” AppleCare fee. I went back to Dell and my beloved Linux.

The laptop isn't as shiny, but Dell comes to you when it breaks. Me and my Apple ID Anyhow, I’m back in Mac.

Central to Apple’s surveillance of me is the Apple ID.

This is my identity to FaceTime, Find My Mac, and all of the tools I use to interact with the new center of my computing existence, Apple.

Google used to be my center. Now I must pray to the ghost of Steve Jobs and kiss the feet of his successor, who has blocked me on Twitter. I tried using my email address with my new work computer.
I didn’t remember the password I used back then. No problem, I could use email validation or my birthday.
I tried my birthday because it's faster, but it didn’t work -- odd, but maybe I fat-fingered it or my ex-wife put in her birthday at some point. No matter, I used email verification and changed the password. Apple and various software on my new Mac kept calling me a female name.
I thought that was odd, so I logged in to appleid.apple.com and figured I’d change my birthday. Now it wanted to verify my favorite elementary school teacher’s name and favorite band in high school.
I wouldn’t have picked either of those because, duh, I reference music in my blog too much.
I was also a terrible student, preferring the library to the classroom and asking too many questions.

Apple rejected both. I called Apple support.

There, I talked to J, who was incredibly helpful and did everything he possibly could with the broken system, but I was at the mercy of a certain "A" from Canada. We tried to change the security questions, but those sent a verification code to “A***’s iPod Touch.” After a few other attempts, we determined this wasn’t actually my Apple ID account. As it turns out, I still had an Apple ID from a time before Apple demanded email addresses. Unfortunately, four years ago, when Apple began asking for them, you didn’t need to verify the email address.
So a young lady ("A," as noted above) with the same last name as me and a different first name used my Gmail address as her Apple ID but didn’t validate it. Apple Support and I tried several different ways to let me recover my email address, but finally, I found A’s number on her Apple ID account and texted her.
Someone else answered and promised to ask A to look into this.

This took four hours.

Apple kindly offered me free accessories once we were done. Invalidated credentials Apple’s often lauded security has been evolutionary -- and often a series of “oops, we’ll fix that” moves. Unfortunately, this goes to show you that failing to follow basic security patterns (like, is this really your email address?) allowed another person to inadvertently compromise my security. When Apple “fixed” the problem, it still had an unvalidated credential it had grandfathered in.

This allowed me to compromise A’s security.
In this case, no one was malicious.

But I don’t want to deal with yet another email address. What Apple should have done was to treat everyone’s not-yet-validated Apple ID email addresses as suspect -- and made people validate them or change them to a validated address.

An unvalidated credential is an unvalidated credential. Which brings us to the moral of our story: Validate credentials! (Also: Linux is easier to use than iOS, and Google is my preferred surveillance and security authority.) If a credential proves invalid, don’t simply change the process, invalidate the credential, and force it to be validated before it's used or even associated.

Failing to do this not only compromises the security of the person with the invalid credential but possibly the security of the person it belongs to as well.