Security updates have been issued by CentOS (linux-firmware and microcode_ctl), Fedora (icecat and transmission), Oracle (java-1.8.0-openjdk and microcode_ctl), Red Hat (java-1.8.0-openjdk), Scientific Linux (java-1.8.0-openjdk), Slackware (bind), SUSE (kernel), and Ubuntu (eglibc).
Security updates have been issued by Debian (bind9, wordpress, and xbmc), Fedora (awstats, docker, gifsicle, irssi, microcode_ctl, mupdf, nasm, osc, osc-source_validator, and php), Gentoo (newsbeuter, poppler, and rsync), Mageia (gifsicle), Red Hat (linux-firmware and microcode_ctl), Scientific Linux (linux-firmware and microcode_ctl), SUSE (kernel and openssl), and Ubuntu (bind9, eglibc, glibc, and transmission).
Post Syndicated from Ernesto original https://torrentfreak.com/bittorrent-client-transmission-suffers-remote-takeover-vulnerability-180116/
With millions of active users, Transmission is one of the most used BitTorrent clients around, particularly for Mac users.
The application has been around for more than a decade and has a great reputation. However, as with any other type of software, it is not immune to vulnerabilities.
One rather concerning flaw was made public by Google vulnerability researcher Tavis Ormandy a few days ago. The flaw allows outsiders to gain access to Transmission via DNS rebinding. This ultimately allows attackers to control the BitTorrent client and execute custom code.
Ormandy has published a patch, which was also shared with the private Transmission security list at the end of November. Transmission, however, has yet to address the issue in an update.
The relatively slow response was the reason why Ormandy decided to make it public before Project Zero’s usual 90-day window expired, Ars highlights. This allows other projects to address the vulnerability right away.
“I’m finding it frustrating that the transmission developers are not responding on their private security list,” Google’s vulnerability researcher writes. “I’ve never had an opensource project take this long to fix a vulnerability before, so I usually don’t even mention the 90 day limit if the vulnerability is in an open source project.”
A member of the Transmission developer team informed Ars that they will address this ASAP, noting that the issue only affects users who have remote control enabled with the default password. This means that people who disable it or change their password can easily ‘patch’ it until the official update comes out.
Interestingly, this isn’t the last BitTorrent related vulnerability Ormandy plans to expose. According to one of his tweets on the matter, this is just the “first of a few remote code execution flaws in various popular torrent clients.”
Judging from a message the researcher sent late November, uTorrent is on the list as well. Apparently, the company’s security email address wasn’t set up correctly at the time, so BitTorrent inventor Bram Cohen has been acting as a forwarding service.
Security updates have been issued by Arch Linux (qtpass), Debian (libkohana2-php, libxml2, transmission, and xmltooling), Fedora (kernel and qpid-cpp), Gentoo (PolarSSL and xen), Mageia (flash-player-plugin, irssi, kernel, kernel-linus, kernel-tmb, libvorbis, microcode, nvidia-current, php & libgd, poppler, webkit2, and wireshark), openSUSE (gifsicle, glibc, GraphicsMagick, gwenhywfar, ImageMagick, libetpan, mariadb, pngcrush, postgresql94, rsync, tiff, and wireshark), and Oracle (kernel).
Post Syndicated from The HiveMQ Team original https://www.hivemq.com/blog/mqtt-5-foundational-changes-in-the-protocol/
Foundational changes in the protocol
While MQTT 5 is a major update to the existing protocol specification, the new version of the lightweight IoT protocol is more of an evolution rather than a revolution and retained all characteristics that contributed to its success: Its lightweightness, push communication, unique features, ease of use, extreme scalability, suitability for mobile networks and decoupling of communication participants.
Although some foundational mechanics were added or changed slightly, the new version still feels like MQTT and it sticks to its principles that made it the most popular Internet of Things protocol to date. This blog post will analyze everything you need to know about the foundational changes in version 5 of the MQTT specification before digging deep into the details of the new features during the next weeks.
MQTT is still MQTT. Mostly.
The good news: If you’re familiar with MQTT 3.1.1 (if you aren’t – start here and read the MQTT Essentials first!), then all principles and features you know about MQTT are still valid for MQTT 5. Some details of former features like Last Will and Testament changed a bit or some features were extended and additional popular features implemented by HiveMQ like TTL or Shared Subscriptions were added to the new specification.
The protocol also slightly changed on the wire and an additional control packet (AUTH) was added. But all in all, the MQTT version 5 is still clearly recognizable as MQTT.
Properties in the MQTT Header & Reason Codes
One of the most exciting and most flexible new MQTT 5 features is the possibility to add custom key-value properties in the MQTT header. This feature deserves its own blog post as it is a game changer for many deployments. Similar to protocols like HTTP, MQTT clients and brokers can add an arbitrary number of custom (or pre-defined) headers to carry metadata. This metadata can be used for application specific data. Pre-defined headers are used for the implementation of most of the new MQTT features.
Many MQTT packets now also include Reason Codes. A Reason Code indicates that a pre-defined protocol error occurred. These reason codes are typically carried on acknowledgement packets and allow client and broker to interpret error conditions (and potentially work around them). The Reason Codes are sometimes called Negative Acknowledgements. The following MQTT packets can carry Reason Codes:
Reason Codes for negative acknowledgements range from “Quota Exceeded” to “Protocol Error”. Clients and brokers are responsible for interpreting these new Reason Codes.
CONNACK Return Codes for unsupported features
With the popularity of MQTT, a lot of MQTT implementations were created and offered by companies. Not all of these implementations are completely MQTT specification compatible since sometimes features are not implemented like QoS 2, retained messages or persistent sessions. On a side note, HiveMQ is of course fully MQTT specification conformal and supports all features.
MQTT 5 provides a way for incomplete MQTT implementations (as often found in SaaS offerings) to indicate that the broker does not support specific features. It’s the client’s job to make sure that none of the unsupported features are used. The broker implementation uses pre-defined headers in the CONNACK packet (which is sent by the broker after the client sent a CONNECT packet) to indicate that specific features are not supported. These headers can of course also be used to send a notice to the client that it has no permission to use specific features.
The following pre-defined headers for indicating unimplemented features (or features not permitted for use by the client) are available in MQTT 5:
|Pre-Defined Header||Data Type||Description|
|Retain Available||Boolean||Are retained messages available?|
|Maximum QoS||Boolean||The maximum QoS the client is allowed to use for publishing messages or subscribing to topics|
|Wildcard available||Boolean||If Wildcards can be used for topic subscriptions|
|Subscription identifiers available||Boolean||If Subscription Identifiers are available for the MQTT client|
|Shared Subscriptions available||Boolean||If Shared Subscriptions are available for the MQTT client|
|Maximum Message Size||Number||Defines the maximum message size a MQTT client can use|
|Server Keep Alive||Number||The Keep Alive Interval the server supports for the individual client|
These return codes are a major step forward for communicating the permissions of individual MQTT clients in heterogeneous environments. The downside of this new functionality is that MQTT clients need to implement the interpretation of these codes themselves and need to make sure that application programmers don’t use features that are not supported by the broker (or the client has no permission for).
HiveMQ is going to support all MQTT 5 features 100%, so these custom headers are only expected to be used if the administrator choses to use them for permissions in deployments.
Clean Session is now Clean Start
A popular MQTT 3.1.1 functionality is the use of clean sessions by MQTT clients, which have temporary connections or don’t subscribe to messages at all. When connecting to the broker, the client had to choose to send a CONNECT packet with the cleanSession flag enabled or disabled. With a clean session, a MQTT client indicates that the broker should discard any data for the client as soon as the underlying TCP connection breaks or if the client decides to disconnect from the broker. Also, if there was a previous session associated with the client identifier on the broker, a cleanSession CONNECT packet forced the broker to delete the previous data.
With MQTT 5, a client can choose to use a Clean Start (indicated by the Clean Start flag in the CONNECT message). When using this flag, the broker discards any previous session data and the client starts with a fresh session. The session won’t be cleaned automatically after the TCP connection was closed between client and server. To trigger the deletion of the session after the client disconnected, a new header field called “Session Expiry Interval” must be set to the value 0.
The new Clean Start streamlines and simplifies the session handling of MQTT, as it allows more flexibility and is easier to implement than the cleanSession/persistent session concept. With MQTT 5 all session are persistent unless the “Session Expiry Interval” is 0. Deletion of a session occurs after the timeout or when the client reconnects with Clean Start.
Additional MQTT Packet
MQTT 5 introduces a new MQTT Packet: The AUTH packet. This new packet is extremely useful for implementing non-trivial authentication mechanisms and we expect that this packet will be used a lot in production environments. The exact semantics are covered in a future blog post.
For the moment, it’s important to realize that this new packet can be sent by brokers and clients after connection establishment to use complex challenge/response authentication methods (like SCRAM or Kerberos as defined in the SAML framework, but can also be used for state-of-the-art authentication methods for IoT like OAuth. This packet also allows re-authentication of MQTT clients without closing the connection. Stay tuned for a deep dive into the packet very soon!
New Data Type: UTF-8 String pairs
The advent of custom headers also required a new data type to be introduced. UTF-8 string pairs. This string pair is essentially a key-value structure with both, key and value, as String data type. This data type is currently only used for custom headers.
With this new data type, MQTT uses 7 different data types that are used on the wire:
- Two Byte Integer
- Four Byte Integer
- UTF-8 Encoded String
- Variable Byte Integer
- Binary Data
- UTF-8 String Pair
Most application users typically use Binary Data and UTF-8 encoded Strings in the APIs of their MQTT library. With MQTT 5, UTF-8 String Pairs may also be used frequently. All other data types are hidden from the user but are used on the wire to craft valid MQTT packets by the MQTT client libraries and brokers.
Bi-directional DISCONNECT packets
With MQTT 3.1.1, the client could indicate that it wanted to disconnect gracefully by sending a DISCONNECT packet prior to closing the underlying TCP connection. There was no way for the MQTT broker to notify a MQTT client that something bad happened and that the broker is going to close the TCP connection. This changed with the new protocol version.
The broker is now allowed to send a MQTT DISCONNECT packet prior to closing the socket. The client is now able to interpret the reason why it was disconnected and take the respective action. A broker is not required to indicate the exact reason (e.g. for security reasons), but at least for developing applications this helps a lot to figure out why a connection was closed by the broker.
Of course DISCONNECT packets can carry Reason Codes, so it’s easy to indicate what was the reason for the disconnection (e.g. in case of invalid permissions).
No retry for QoS 1 and 2 messages
MQTT clients use standing TCP (or similar protocols with the same guarantees) connections as underlying transport. A healthy TCP connection gives bi-directional connectivity with exactly-once and in-order guarantees, so all MQTT packets sent by clients or brokers will arrive on the other end. In case the TCP connection breaks, while the message is in-flight, QoS 1 and 2 give message delivery guarantees over multiple TCP connections.
MQTT 3.1.1 allowed the re-delivery of MQTT messages while the TCP connection is healthy. In practice, this is a very bad idea, since overloaded MQTT clients may get overloaded even more. Just imagine a case where a MQTT client receives a message from a MQTT broker and needs 11 seconds to process the message (and would acknowledge the packet after the processing). Now imagine the broker would retransmit the message after a 10 second timeout. There is no advantage to this approach and it just uses precious bandwidth and overloads the MQTT client even more.
With MQTT 5, brokers and clients are not allowed to retransmit MQTT messages for healthy TCP connections. The brokers and clients must re-send unacknowledged packets when the TCP connection was closed, though. So the QoS 1 and 2 guarantees are as important as with MQTT 3.1.1.
In case you rely on retransmission packets in your use case (e.g. because your implementation does not acknowledge packets in certain cases), we suggest reconsidering this decision before upgrading to MQTT 5.
Using passwords without usernames
MQTT 3.1.1 required the MQTT client to send a username when using a password in the CONNECT packet. For certain use cases this was very inconvenient in case there was no username. A good example would be the use of OAuth, which uses a JSON web token as the only authentication and authorization information. When using such a token with MQTT 3.1.1, static usernames were used frequently, as the only relevant information was in the password field.
While there are more elegant ways in MQTT 5 to carry tokens (e.g. via the AUTH packet), it is still possible to utilize the password field of the CONNECT packet. Now users can just use the password field and don’t need to fill out the username anymore.
Although the MQTT protocol stays basically the same, there are some small changes under the hood, which are enablers for many of the new features in version 5 of the popular IoT protocol. As a user of MQTT libraries, most of these changes are good to know but do not affect how MQTT is used. Developers for MQTT libraries and brokers need to take care of the changes, especially on the changes on the protocol nitty-grittys. There were also some small changes in the specified behavior (e.g. retransmission of messages), so it’s good to revisit design decisions of deployments when upgrading to MQTT 5.
What do you like most of the foundational changes in MQTT? Let us know in the comments!
Have an awesome week,
The HiveMQ Team
Post Syndicated from Yev original https://www.backblaze.com/blog/backblaze-cloud-backup-release-5-2/
We’re pleased to start the year off the right way, with an update to Backblaze Cloud Backup, version 5.2! This is a smaller release, but does increase backup speeds, optimizes the backup client, and addresses a few minor bugs that we’re excited to lay to rest.
- Increased transmission speed of files between 30MB and 400MB+.
- Optimized indexing to decrease system resource usage and lower the performance impact on computers that are backing up to Backblaze.
- Adjusted external hard drive monitoring and increased the speed of indexing.
- Changed copyright to 2018.
Release Version Number:
Backblaze Personal Backup
Backblaze Business Backup
January 4, 2018
- Immediately as a download from: files.backblaze.com
- Rolling out soon when performing a “Check for Updates” (right-click on the Backblaze icon and then select “Check for Updates”).
- Rolling out soon as a download from: https://secure.backblaze.com/update.htm.
- Rolling out soon as the default download from: www.backblaze.com.
- Auto-update will begin in a couple of weeks.
This is a free update for all Backblaze Cloud Backup consumer and business customers and active trial users.
Post Syndicated from Andy original https://torrentfreak.com/dish-network-files-two-lawsuits-against-pirate-iptv-providers-180103/
In broad terms, there are two types of unauthorized online streaming of live TV. The first is via open-access websites where users can view for free. The second features premium services to which viewers are required to subscribe.
Usually available for a few dollars, euros, or pounds per month, the latter are gaining traction all around the world. Service levels are relatively high and the majority of illicit packages offer a dazzling array of programming, often putting official providers in the shade.
For this reason, commercial IPTV providers are considered a huge threat to broadcasters’ business models, since they offer a broadly comparable and accessible service at a much cheaper price. This is forcing companies such as US giant Dish Networks to court, seeking relief.
Following on from a lawsuit filed last year against Kodi add-on ZemTV and TVAddons.ag, Dish has just filed two more lawsuits targeting a pair of unauthorized pirate IPTV services.
Filed in Maryland and Texas respectively, the actions are broadly similar, with the former targeting a provider known as Spider-TV.
The suit, filed against Dima Furniture Inc. and Mohammad Yusif (individually and collectively doing business as Spider-TV), claims that the defendants are “capturing
broadcasts of television channels exclusively licensed to DISH and are unlawfully retransmitting these channels over the Internet to their customers throughout the United States, 24 hours per day, 7 days per week.”
Dish claim that the defendants profit from the scheme by selling set-top boxes along with subscriptions, charging around $199 per device loaded with 13 months of service.
Dima Furniture is a Maryland corporation, registered at Takoma Park, Maryland 20912, an address that is listed on the Spider-TV website. The connection between the defendants is further supported by FCC references which identify Spider devices in the market. Mohammad Yusif is claimed to be the president, executive director, general manager, and sole shareholder of Dima Furniture.
Dish describes itself as the fourth largest pay-television provider in the United States, delivering copyrighted programming to millions of subscribers nationwide by means of satellite delivery and over-the-top services. Dish has acquired the rights to do this, the defendants have not, the broadcaster states.
“Defendants capture live broadcast signals of the Protected Channels, transcode these signals into a format useful for streaming over the Internet, transfer the transcoded content to one or more servers provided, controlled, and maintained by Defendants, and then transmit the Protected Channels to users of the Service through
OTT delivery, including users in the United States,” the lawsuit reads.
It’s claimed that in July 2015, Yusif registered Spider-TV as a trade name of Dima Furniture with the Department of Assessments and Taxation Charter Division, describing the business as “Television Channel Installation”. Since then, the defendants have been illegally retransmitting Dish channels to customers in the United States.
The overall offer from Spider-TV appears to be considerable, with a claimed 1,300 channels from major regions including the US, Canada, UK, Europe, Middle East, and Africa.
Importantly, Dish state that the defendants know that their activities are illegal, since the provider sent at least 32 infringement notices since January 20, 2017 demanding an end to the unauthorized retransmission of its channels. It went on to send even more to the defendants’ ISPs.
“DISH and Networks sent at least thirty-three additional notices requesting the
removal of infringing content to Internet service providers associated with the Service from February 16, 2017 to the filing of this Complaint. Upon information and belief, at least some of these notices were forwarded to Defendants,” the lawsuit reads.
But while Dish says that the takedowns responded to by the ISPs were initially successful, the defendants took evasive action by transmitting the targeted channels from other locations.
Describing the defendants’ actions as “willful, malicious, intentional [and] purposeful”, Dish is suing for Direct Copyright Infringement, demanding a permanent injunction preventing the promotion and provision of the service plus statutory damages of $150,000 per registered work. The final amount isn’t specified but the numbers are potentially enormous. In addition, Dish demands attorneys’ fees, costs, and the seizure of all infringing articles.
The second lawsuit, filed in Texas, is broadly similar. It targets Mo’ Ayad Al
Zayed Trading Est., and Mo’ Ayad Fawzi Al Zayed (individually and collectively doing business as Tiger International Company), and Shenzhen Tiger Star Electronical Co., Ltd, otherwise known as Shenzhen Tiger Star.
Dish claims that these defendants also illegally capture and retransmit channels to customers in the United States. IPTV boxes costing up to $179 including one year’s service are the method of delivery.
In common with the Maryland case, Dish says it sent almost two dozen takedown notices to ISPs utilized by the defendants. These were also countered by the unauthorized service retransmitting Dish channels from other servers.
The biggest difference between the Maryland and Texas cases is that while Yusif/Spider/Dima Furniture are said to be in the US, Zayed is said to reside in Amman, Jordan, and Tiger Star is registered in Shenzhen, China. However, since the unauthorized service is targeted at customers in Texas, Dish states that the Texas court has jurisdiction.
Again, Dish is suing for Direct Infringement, demanding damages, costs, and a permanent injunction.
Post Syndicated from Andy original https://torrentfreak.com/iptv-provider-stops-selling-new-subscriptions-under-pressure-from-uk-authorities-171224/
Over the past couple of decades, piracy of live TV has broadly taken two forms. That which relies on breaking broadcaster encryption (such as card sharing and hacked set-top boxes), and the more recent developments of P2P and IPTV-style transmission.
With the former under pressure and P2P systems such as Sopcast and AceTorrent moving along in the background, streaming from servers is now the next big thing, whether that’s for free via third-party Kodi plugins or for a small fee from premium IPTV providers.
Of course, copyright holders don’t like any of this usage but with their for-profit strategy, commercial IPTV providers have a big target on their backs. More evidence of this was revealed recently when UK-based IPTV service ACE TV announced they were taking action to avoid problems in the country.
In a message to prospective and existing customers, ACE TV said that potential legal issues were behind its decision to accept no new customers while locking down its service.
“It saddens me to announce this, but due to pressure from the authorities in the UK, we are no longer selling new subscriptions. This obviously includes trials,” the announcement reads.
Noting that it would take new order for just 24 hours more, ACE TV insisted that it wasn’t shutting down but would lock down the service while closing Facebook.
TF sources and unconfirmed rumors online suggest that the Federation Against Copyright Theft and partners the Premier League are involved. However, ACE TV didn’t respond to TorrentFreak’s request for comment so we’re unable to confirm or deny the allegations.
That being said, even if the threats came directly from the police, it’s likely that the approach would’ve been initially prompted by companies connected to FACT, since the anti-piracy outfit often puts forward names of services for investigation on behalf of its partners.
Perhaps surprisingly, ACE TV is legally incorporated in the UK as Ace Hosting Limited, a fact it makes clear on its website. While easy to find, the company’s registered address is shared by dozens of other companies, indicating a mail forwarding operation rather than a place servers or staff can be found.
This proxy location may well be the reason the company feels emboldened to carry on some level of service rather than shutting down completely, but its legal basis for doing so is interesting at best, precarious at worst.
“This website, any content contained herein and any contract brought into being as a result of usage of this website are governed by and construed in accordance with English Law,” ACE TV’s website reads.
“The parties to any such contract agree to submit to the exclusive jurisdiction of the courts of England and Wales. All contracts are concluded in English.”
It seems likely that ACE TV has been threatened under UK law, since that’s where it’s incorporated. That would seem to explain why its concerned about UK authorities and their potential effect on the business. On the other hand, however, the service claims to operate entirely legally, but under the laws of the United States. It even has a repeat infringer policy.
“Ace Hosting operates as an intermediary to cache and deliver content hosted by others at the instruction of our subscribers. We cannot remove content hosted by others,” the company says.
“As an intermediary, we are entitled to rely upon (among other things) the DMCA safe harbor available to system caching service providers and we maintain policies and procedures to terminate subscribers that would be considered repeat infringers under the DMCA.”
Whether the notices on the site have been advised by a legal professional or are there to present an air of authenticity is unclear but it’s precarious for a service of this nature to rely solely on conduit status in order to avoid liability.
Marketing, prior conduct, and overall intent play a major role in such cases and when all of that is aired in the cold light of day, the situation can look very different to a judge, particularly in the UK, where no similar cases have been successfully defended to date.
2017 has been a busy year for Backblaze. We’ve reached a total of over 400 petabytes of data stored for our customers — that’s a lot!, released a major upgrade to our backup product — Backblaze Cloud Backup 5.0, added Groups to our consumer and business backup products, further enhanced account security, and welcomed a whole lot of new customers to Backblaze.
Blazing Power Tips for Backblaze Backup
Back Up All of Your Valuable Data
Include Directly-Attached External Drives in Your Backup
Backblaze can back up external drives attached via USB, Thunderbolt, or Firewire.
Back Up Virtual Machines Installed on Your Computer
Virtual machines, such as those created by Parallels, VMware Fusion, VirtualBox, Hyper-V, or other programs, can be backed up with Backblaze.
You Can Back Up Your Mobile Phone to Backblaze
Gain extra peace-of-mind by backing up your iPhone or Android phone to your computer and including that in your computer backup.
Bring on Your Big Files
By default, Backblaze has no restrictions on the size of the files you are backing up, even that large high school reunion video you want to be sure to keep.
Rescan Your Hard Drive to Check for Changes
Backblaze works quietly and continuously in the background to keep you backed up, but you can ask Backblaze to immediately check whether anything needs backing up by holding down the Alt key and clicking on the Restore Options button in the Backblaze client.
Manage and Restore Your Backed Up Files
You Can Share Files You’ve Backed Up
You can share files with anyone directly from your Backblaze account.
Select and Restore Individual Files
You can restore a single file without zipping it using the Backblaze web interface.
Receive Your Restores from Backblaze by Mail
You have a choice of how to receive your data from Backblaze. You can download individual files, download a ZIP of the files you choose, or request that your data be shipped to you anywhere in the world via FedEx.
Put Your Account on Hold for Six Months
As long as your account is current, all the data you’ve backed up is maintained for up to six months if you’re traveling or not using your computer and don’t connect to our servers. (For active accounts, data is maintained up to 30 days.)
Groups Make Managing Business or Family Members Easy
You Can Browse and Restore Previous Versions of a File
Visit the View/Restore Files page to go back in time to earlier or deleted versions of your files.
Mass Deploy Backblaze Remotely to Many Computers
Companies, organizations, schools, non-profits, and others can deploy Backblaze computer backup remotely across all their computers without any end-user interaction.
Move Your Account and Preserve Backups on a New or Restored Computer
You can move your Backblaze account to a new or restored computer with the same data — and preserve the backups you have already completed — using the Inherit Backup State feature.
Reinstall Backblaze under a Different Account
Backblaze remembers the account information when it is uninstalled and reinstalled. To install Backblaze under a different account, hold down the ALT key and click the Install Now button.
Keep Your Data Secure
Protect Your Account with Two-Factor Verification
You can (and should) protect your Backblaze account with two-factor verification. You can use backup codes and SMS verification in case you lose access to your smartphone and the authentication app. Sign in to your account to set that up.
Add Additional Security to Your Data
All transmissions of your data between your system and our servers is encrypted. For extra account security, you can add an optional private encryption key (PEK) to the data on our servers. Just be sure to remember your encryption key because it’s required to restore your data.
Get the Best Data Transfer Speeds
How Fast is your Connection to Backblaze?
You can check the speed and latency of your internet connection between your location and Backblaze’s data centers at https://www.backblaze.com/speedtest/.
Fine-Tune Your Upload Speed with Multiple Threads
Our auto-threading feature adjusts Backblaze’s CPU usage to give you the best upload speeds, but for those of you who like to tinker, the Backblaze client on Windows and Macintosh lets you fine-tune the number of threads our client is using to upload your files to our data centers.
Use the Backblaze Downloader To Get Your Restores Faster
Want to Learn More About Backblaze Backup?
Do you have a friend who should be backing up, but doesn’t? Why not give the gift of Backblaze?
Post Syndicated from Andy original https://torrentfreak.com/eu-court-cloud-based-tv-recorder-requires-rightsholder-permission-171130/
But while many such devices have been consumed by history, their modern equivalents still pose tricky questions for copyright law. One such service is VCAST, which markets itself as a Video Cloud Recorder. It functions in a notionally similar way to its older cousin but substitutes cassette storage for that in the cloud.
VCAST targets the Italian market, allowing users to sign up in order to gain access to more than 50 digital terrestrial TV channels. However, rather than simply watching live, the user can tell VCAST to receive TV shows (via its own antenna system) while recording them to private cloud storage (such as Google Drive) for subsequent viewing over the Internet.
VCAST attracted the negative interests of rightsholders, including Mediaset-owned RTI, who doubted the legality of the service. So, in response, VCAST sued RTI at the Turin Court of First Instance, seeking a judgment confirming the legality of its operations. The company believed that since the recordings are placed in users’ own cloud storage, the Italian private copying exception would apply and rightsholders would be compensated.
Perhaps unsurprisingly given the complexity of the case, the Turin Court decided to refer questions to the European Court of Justice. It essentially asked whether the private copying exception is applicable when the copying requires a service like VCAST and whether such a service is allowed to operate without permission from copyright holders.
In September, Advocate General Szpunar published his opinion, concluding that EU law prohibits this kind of service when copyright holders haven’t given their permission. Today, the ECJ handed down its decision, broadly agreeing with Szpunar’s conclusion.
“By today’s judgment, the Court finds that the service provided by VCAST has a dual functionality, consisting in ensuring both the reproduction and the making available of protected works. To the extent that the service offered by VCAST consists in the making available of protected works, it falls within communication to the public,” the ECJ announced.
“In that regard, the Court recalls that, according to the directive, any communication to the public, including the making available of a protected work or subject-matter, requires the rightholder’s consent, given that the right of communication of works to the public should be understood, in a broad sense, as covering any transmission or retransmission of a work to the public by wire or wireless means, including broadcasting.”
The ECJ notes that the original transmission made by RTI was intended for one audience. In turn, the transmission by VCAST was intended for another. In this respect, the subsequent VCAST transmission was made to a “new public”, which means that copyright holder permission is required under EU law.
“Accordingly, such a remote recording service cannot fall within the private copying exception,” the ECJ concludes.
The full text of the judgment can be found here.
The key ruling reads as follows:
Directive 2001/29/EC of the European Parliament and of the Council of 22 May 2001 on the harmonisation of certain aspects of copyright and related rights in the information society, in particular Article 5(2)(b) thereof, must be interpreted as precluding national legislation which permits a commercial undertaking to provide private individuals with a cloud service for the remote recording of private copies of works protected by copyright, by means of a computer system, by actively involving itself in the recording, without the rightholder’s consent.
Post Syndicated from Andy original https://torrentfreak.com/game-of-thrones-leaks-carried-out-by-former-iranian-military-hacker-171122/
Late July it was reported that hackers had stolen proprietary information from media giant HBO.
The haul was said to include confidential details of the then-unreleased fourth episode of the latest Game of Thrones season, plus episodes of Ballers, Barry, Insecure, and Room 104.
“Hi to all mankind,” an email sent to reporters read. “The greatest leak of cyber space era is happening. What’s its name? Oh I forget to tell. Its HBO and Game of Thrones……!!!!!!”
In follow-up correspondence, the hackers claimed to have penetrated HBO’s internal network, gaining access to emails, technical platforms, and other confidential information.
Soon after, HBO chairman and CEO Richard Plepler confirmed a breach at his company, telling employees that there had been a “cyber incident” in which information and programming had been taken.
“Any intrusion of this nature is obviously disruptive, unsettling, and disturbing for all of us. I can assure you that senior leadership and our extraordinary technology team, along with outside experts, are working round the clock to protect our collective interests,” he said.
During mid-August, problems persisted, with unreleased shows hitting the Internet. HBO appeared rattled by the ongoing incident, refusing to comment to the media on every new development. Now, however, it appears the tide is turning on HBO’s foe.
In a statement last evening, Joon H. Kim, Acting United States Attorney for the Southern District of New York, and William F. Sweeney Jr., Assistant Director-in-Charge of the New York Field Division of the FBI, announced the unsealing of an indictment charging a 29-year-old man with offenses carried out against HBO.
“Behzad Mesri, an Iranian national who had previously hacked computer systems for the Iranian military, allegedly infiltrated HBO’s systems, stole proprietary data, including scripts and plot summaries for unaired episodes of Game of Thrones, and then sought to extort HBO of $6 million in Bitcoins,” Kim said.
“Mesri now stands charged with federal crimes, and although not arrested today, he will forever have to look over his shoulder until he is made to face justice. American ingenuity and creativity is to be cultivated and celebrated — not hacked, stolen, and held for ransom. For hackers who test our resolve in protecting our intellectual property — even those hiding behind keyboards in countries far away — eventually, winter will come.”
According to the Department of Justice, Mesri honed his computer skills working for the Iranian military, conducting cyber attacks against enemy military systems, nuclear software, and Israeli infrastructure. He was also a member of the Turk Black Hat hacking team which defaced hundreds of websites with the online pseudonym “Skote Vahshat”.
The indictment states that Mesri began his campaign against HBO during May 2017, when he conducted “online reconnaissance” of HBO’s networks and employees. Between May and July, he then compromised a number of HBO employee user accounts and used them to access the company’s data and TV shows, copying them to his own machines.
After allegedly obtaining around 1.5 terabytes of HBO’s data, Mesri then began to extort HBO, warning that unless a ransom of $5.5 million wasn’t paid in Bitcoin, the leaking would begin. When the amount wasn’t paid, three days later Mesri told HBO that the amount had now risen to $6m and as an additional punishment, data could be wiped from HBO’s servers.
Subsequently, on or around July 30 and continuing through August 2017, Mesri allegedly carried through with his threats, leaking information and TV shows online and promoting them via emails to members of the press.
As a result of the above, Mesri is charged with one count of wire fraud, which carries a maximum sentence of 20 years in prison, one count of computer hacking (five years), three counts of threatening to impair the confidentiality of information (five years each), and one count of interstate transmission of an extortionate communication (two years). No copyright infringement offenses are mentioned in the indictment.
The big question now is whether the US will ever get their hands on Mesri. The answer to that, at least through any official channels, seems to be a resounding no. There is no extradition treaty between the US and Iran meaning that if Mesri stays put, he’s likely to remain a free man.
Post Syndicated from Robert Graham original http://blog.erratasec.com/2017/10/some-notes-on-krack-attack.html
This is my interpretation of the KRACK attacks paper that describes a way of decrypting encrypted WiFi traffic with an active attack.
tl;dr: Wow. Everyone needs to be afraid. (Well, worried — not panicked.) It means in practice, attackers can decrypt a lot of wifi traffic, with varying levels of difficulty depending on your precise network setup. My post last July about the DEF CON network being safe was in error.
This is an active attack, not a passive attack, so in theory, it’s detectable.
Who is vulnerable?
How can I defend myself?
Post Syndicated from Vijay Sharma original https://aws.amazon.com/blogs/security/how-to-enable-ldaps-for-your-aws-microsoft-ad-directory/
Starting today, you can encrypt the Lightweight Directory Access Protocol (LDAP) communications between your applications and AWS Directory Service for Microsoft Active Directory, also known as AWS Microsoft AD. Many Windows and Linux applications use Active Directory’s (AD) LDAP service to read and write sensitive information about users and devices, including personally identifiable information (PII). Now, you can encrypt your AWS Microsoft AD LDAP communications end to end to protect this information by using LDAP Over Secure Sockets Layer (SSL)/Transport Layer Security (TLS), also called LDAPS. This helps you protect PII and other sensitive information exchanged with AWS Microsoft AD over untrusted networks.
To enable LDAPS, you need to add a Microsoft enterprise Certificate Authority (CA) server to your AWS Microsoft AD domain and configure certificate templates for your domain controllers. After you have enabled LDAPS, AWS Microsoft AD encrypts communications with LDAPS-enabled Windows applications, Linux computers that use Secure Shell (SSH) authentication, and applications such as Jira and Jenkins.
In this blog post, I show how to enable LDAPS for your AWS Microsoft AD directory in six steps: 1) Delegate permissions to CA administrators, 2) Add a Microsoft enterprise CA to your AWS Microsoft AD directory, 3) Create a certificate template, 4) Configure AWS security group rules, 5) AWS Microsoft AD enables LDAPS, and 6) Test LDAPS access using the LDP tool.
For this post, I assume you are familiar with following:
- Creating an Amazon EC2 for Windows Server instance and seamlessly joining it to your AWS Microsoft AD domain.
- Logging in to an Amazon EC2 for Windows Server instance using Remote Desktop Protocol (RDP).
- Launching and using Microsoft Windows Server Manager.
- Launching Windows PowerShell with administrative privileges and running Windows PowerShell scripts.
Before going into specific deployment steps, I will provide a high-level overview of deploying LDAPS. I cover how you enable LDAPS on AWS Microsoft AD. In addition, I provide some general background about CA deployment models and explain how to apply these models when deploying Microsoft CA to enable LDAPS on AWS Microsoft AD.
How you enable LDAPS on AWS Microsoft AD
LDAP-aware applications (LDAP clients) typically access LDAP servers using Transmission Control Protocol (TCP) on port 389. By default, LDAP communications on port 389 are unencrypted. However, many LDAP clients use one of two standards to encrypt LDAP communications: LDAP over SSL on port 636, and LDAP with StartTLS on port 389. If an LDAP client uses port 636, the LDAP server encrypts all traffic unconditionally with SSL. If an LDAP client issues a StartTLS command when setting up the LDAP session on port 389, the LDAP server encrypts all traffic to that client with TLS. AWS Microsoft AD now supports both encryption standards when you enable LDAPS on your AWS Microsoft AD domain controllers.
You enable LDAPS on your AWS Microsoft AD domain controllers by installing a digital certificate that a CA issued. Though Windows servers have different methods for installing certificates, LDAPS with AWS Microsoft AD requires you to add a Microsoft CA to your AWS Microsoft AD domain and deploy the certificate through autoenrollment from the Microsoft CA. The installed certificate enables the LDAP service running on domain controllers to listen for and negotiate LDAP encryption on port 636 (LDAP over SSL) and port 389 (LDAP with StartTLS).
Background of CA deployment models
You can deploy CAs as part of a single-level or multi-level CA hierarchy. In a single-level hierarchy, all certificates come from the root of the hierarchy. In a multi-level hierarchy, you organize a collection of CAs in a hierarchy and the certificates sent to computers and users come from subordinate CAs in the hierarchy (not the root).
Certificates issued by a CA identify the hierarchy to which the CA belongs. When a computer sends its certificate to another computer for verification, the receiving computer must have the public certificate from the CAs in the same hierarchy as the sender. If the CA that issued the certificate is part of a single-level hierarchy, the receiver must obtain the public certificate of the CA that issued the certificate. If the CA that issued the certificate is part of a multi-level hierarchy, the receiver can obtain a public certificate for all the CAs that are in the same hierarchy as the CA that issued the certificate. If the receiver can verify that the certificate came from a CA that is in the hierarchy of the receiver’s “trusted” public CA certificates, the receiver trusts the sender. Otherwise, the receiver rejects the sender.
Deploying Microsoft CA to enable LDAPS on AWS Microsoft AD
Microsoft offers a standalone CA and an enterprise CA. Though you can configure either as single-level or multi-level hierarchies, only the enterprise CA integrates with AD and offers autoenrollment for certificate deployment. Because you cannot sign in to run commands on your AWS Microsoft AD domain controllers, an automatic certificate enrollment model is required. Therefore, AWS Microsoft AD requires the certificate to come from a Microsoft enterprise CA that you configure to work in your AD domain. When you install the Microsoft enterprise CA, you can configure it to be part of a single-level hierarchy or a multi-level hierarchy. As a best practice, AWS recommends a multi-level Microsoft CA trust hierarchy consisting of a root CA and a subordinate CA. I cover only a multi-level hierarchy in this post.
In a multi-level hierarchy, you configure your subordinate CA by importing a certificate from the root CA. You must issue a certificate from the root CA such that the certificate gives your subordinate CA the right to issue certificates on behalf of the root. This makes your subordinate CA part of the root CA hierarchy. You also deploy the root CA’s public certificate on all of your computers, which tells all your computers to trust certificates that your root CA issues and to trust certificates from any authorized subordinate CA.
In such a hierarchy, you typically leave your root CA offline (inaccessible to other computers in the network) to protect the root of your hierarchy. You leave the subordinate CA online so that it can issue certificates on behalf of the root CA. This multi-level hierarchy increases security because if someone compromises your subordinate CA, you can revoke all certificates it issued and set up a new subordinate CA from your offline root CA. To learn more about setting up a secure CA hierarchy, see Securing PKI: Planning a CA Hierarchy.
When a Microsoft CA is part of your AD domain, you can configure certificate templates that you publish. These templates become visible to client computers through AD. If a client’s profile matches a template, the client requests a certificate from the Microsoft CA that matches the template. Microsoft calls this process autoenrollment, and it simplifies certificate deployment. To enable LDAPS on your AWS Microsoft AD domain controllers, you create a certificate template in the Microsoft CA that generates SSL and TLS-compatible certificates. The domain controllers see the template and automatically import a certificate of that type from the Microsoft CA. The imported certificate enables LDAP encryption.
Steps to enable LDAPS for your AWS Microsoft AD directory
The rest of this post is composed of the steps for enabling LDAPS for your AWS Microsoft AD directory. First, though, I explain which components you must have running to deploy this solution successfully. I also explain how this solution works and include an architecture diagram.
The instructions in this post assume that you already have the following components running:
- An active AWS Microsoft AD directory – To create a directory, follow the steps in Create an AWS Microsoft AD directory.
- An Amazon EC2 for Windows Server instance for managing users and groups in your directory – This instance needs to be joined to your AWS Microsoft AD domain and have Active Directory Administration Tools installed. Active Directory Administration Tools installs Active Directory Administrative Center and the LDP tool.
- An existing root Microsoft CA or a multi-level Microsoft CA hierarchy – You might already have a root CA or a multi-level CA hierarchy in your on-premises network. If you plan to use your on-premises CA hierarchy, you must have administrative permissions to issue certificates to subordinate CAs. If you do not have an existing Microsoft CA hierarchy, you can set up a new standalone Microsoft root CA by creating an Amazon EC2 for Windows Server instance and installing a standalone root certification authority. You also must create a local user account on this instance and add this user to the local administrator group so that the user has permissions to issue a certificate to a subordinate CA.
The solution setup
The following diagram illustrates the setup with the steps you need to follow to enable LDAPS for AWS Microsoft AD. You will learn how to set up a subordinate Microsoft enterprise CA (in this case, SubordinateCA) and join it to your AWS Microsoft AD domain (in this case, corp.example.com). You also will learn how to create a certificate template on SubordinateCA and configure AWS security group rules to enable LDAPS for your directory.
As a prerequisite, I already created a standalone Microsoft root CA (in this case RootCA) for creating SubordinateCA. RootCA also has a local user account called RootAdmin that has administrative permissions to issue certificates to SubordinateCA. Note that you may already have a root CA or a multi-level CA hierarchy in your on-premises network that you can use for creating SubordinateCA instead of creating a new root CA. If you choose to use your existing on-premises CA hierarchy, you must have administrative permissions on your on-premises CA to issue a certificate to SubordinateCA.
Lastly, I also already created an Amazon EC2 instance (in this case, Management) that I use to manage users, configure AWS security groups, and test the LDAPS connection. I join this instance to the AWS Microsoft AD directory domain.
Here is how the process works:
- Delegate permissions to CA administrators (in this case, CAAdmin) so that they can join a Microsoft enterprise CA to your AWS Microsoft AD domain and configure it as a subordinate CA.
- Add a Microsoft enterprise CA to your AWS Microsoft AD domain (in this case, SubordinateCA) so that it can issue certificates to your directory domain controllers to enable LDAPS. This step includes joining SubordinateCA to your directory domain, installing the Microsoft enterprise CA, and obtaining a certificate from RootCA that grants SubordinateCA permissions to issue certificates.
- Create a certificate template (in this case, ServerAuthentication) with server authentication and autoenrollment enabled so that your AWS Microsoft AD directory domain controllers can obtain certificates through autoenrollment to enable LDAPS.
- Configure AWS security group rules so that AWS Microsoft AD directory domain controllers can connect to the subordinate CA to request certificates.
- AWS Microsoft AD enables LDAPS through the following process:
- AWS Microsoft AD domain controllers request a certificate from SubordinateCA.
- SubordinateCA issues a certificate to AWS Microsoft AD domain controllers.
- AWS Microsoft AD enables LDAPS for the directory by installing certificates on the directory domain controllers.
- Test LDAPS access by using the LDP tool.
I now will show you these steps in detail. I use the names of components—such as RootCA, SubordinateCA, and Management—and refer to users—such as Admin, RootAdmin, and CAAdmin—to illustrate who performs these steps. All component names and user names in this post are used for illustrative purposes only.
Deploy the solution
Step 1: Delegate permissions to CA administrators
To enable use with a Microsoft enterprise CA, AWS added a new built-in AD security group called AWS Delegated Enterprise Certificate Authority Administrators that has delegated permissions to install and administer a Microsoft enterprise CA. By default, your directory Admin is part of the new group and can add other users or groups in your AWS Microsoft AD directory to this security group. If you have trust with your on-premises AD directory, you can also delegate CA administrative permissions to your on-premises users by adding on-premises AD users or global groups to this new AD security group.
To create a new user (in this case CAAdmin) in your directory and add this user to the AWS Delegated Enterprise Certificate Authority Administrators security group, follow these steps:
- Sign in to the Management instance using RDP with the user name admin and the password that you set for the admin user when you created your directory.
- Launch the Microsoft Windows Server Manager on the Management instance and navigate to Tools > Active Directory Users and Computers.
- Switch to the tree view and navigate to corp.example.com > CORP > Users. Right-click Users and choose New > User.
- Add a new user with the First name CA, Last name Admin, and User logon name CAAdmin.
- In the Active Directory Users and Computers tool, navigate to corp.example.com > AWS Delegated Groups. In the right pane, right-click AWS Delegated Enterprise Certificate Authority Administrators and choose Properties.
- In the AWS Delegated Enterprise Certificate Authority Administrators window, switch to the Members tab and choose Add.
- In the Enter the object names to select box, type CAAdmin and choose OK.
- In the next window, choose OK to add CAAdmin to the AWS Delegated Enterprise Certificate Authority Administrators security group.
- Also add CAAdmin to the AWS Delegated Server Administrators security group so that CAAdmin can RDP in to the Microsoft enterprise CA machine.
You have granted CAAdmin permissions to join a Microsoft enterprise CA to your AWS Microsoft AD directory domain.
Step 2: Add a Microsoft enterprise CA to your AWS Microsoft AD directory
First, you create an Amazon EC2 for Windows Server instance called SubordinateCA and join it to the domain, corp.example.com. You then publish RootCA’s public certificate and certificate revocation list (CRL) to SubordinateCA’s local trusted store. You also publish RootCA’s public certificate to your directory domain. Doing so enables SubordinateCA and your directory domain controllers to trust RootCA. You then install the Microsoft enterprise CA service on SubordinateCA and request a certificate from RootCA to make SubordinateCA a subordinate Microsoft CA. After RootCA issues the certificate, SubordinateCA is ready to issue certificates to your directory domain controllers.
Note that you can use an Amazon S3 bucket to pass the certificates between RootCA and SubordinateCA.
In detail, here is how the process works, as illustrated in the preceding diagram:
- Set up an Amazon EC2 instance joined to your AWS Microsoft AD directory domain – Create an Amazon EC2 for Windows Server instance to use as a subordinate CA, and join it to your AWS Microsoft AD directory domain. For this example, the machine name is SubordinateCA and the domain is corp.example.com.
- Share RootCA’s public certificate with SubordinateCA – Log in to RootCA as RootAdmin and start Windows PowerShell with administrative privileges. Run the following commands to copy RootCA’s public certificate and CRL to the folder c:\rootcerts on RootCA.
Upload RootCA’s public certificate and CRL from c:\rootcerts to an S3 bucket by following the steps in How Do I Upload Files and Folders to an S3 Bucket.
The following screenshot shows RootCA’s public certificate and CRL uploaded to an S3 bucket.
- Publish RootCA’s public certificate to your directory domain – Log in to SubordinateCA as the CAAdmin. Download RootCA’s public certificate and CRL from the S3 bucket by following the instructions in How Do I Download an Object from an S3 Bucket? Save the certificate and CRL to the C:\rootcerts folder on SubordinateCA. Add RootCA’s public certificate and the CRL to the local store of SubordinateCA and publish RootCA’s public certificate to your directory domain by running the following commands using Windows PowerShell with administrative privileges.
- Install the subordinate Microsoft enterprise CA – Install the subordinate Microsoft enterprise CA on SubordinateCA by following the instructions in Install a Subordinate Certification Authority. Ensure that you choose Enterprise CA for Setup Type to install an enterprise CA.
For the CA Type, choose Subordinate CA.
- Request a certificate from RootCA – Next, copy the certificate request on SubordinateCA to a folder called c:\CARequest by running the following commands using Windows PowerShell with administrative privileges.
Upload the certificate request to the S3 bucket.
- Approve SubordinateCA’s certificate request – Log in to RootCA as RootAdmin and download the certificate request from the S3 bucket to a folder called CARequest. Submit the request by running the following command using Windows PowerShell with administrative privileges.
In the Certification Authority List window, choose OK.
Navigate to Server Manager > Tools > Certification Authority on RootCA.
In the Certification Authority window, expand the ROOTCA tree in the left pane and choose Pending Requests. In the right pane, note the value in the Request ID column. Right-click the request and choose All Tasks > Issue.
- Retrieve the SubordinateCA certificate – Retrieve the SubordinateCA certificate by running following command using Windows PowerShell with administrative privileges. The command includes the <RequestId> that you noted in the previous step.
Upload SubordinateCA.crt to the S3 bucket.
- Install the SubordinateCA certificate – Log in to SubordinateCA as the CAAdmin and download SubordinateCA.crt from the S3 bucket. Install the certificate by running following commands using Windows PowerShell with administrative privileges.
- Delete the content that you uploaded to S3 – As a security best practice, delete all the certificates and CRLs that you uploaded to the S3 bucket in the previous steps because you already have installed them on SubordinateCA.
You have finished setting up the subordinate Microsoft enterprise CA that is joined to your AWS Microsoft AD directory domain. Now you can use your subordinate Microsoft enterprise CA to create a certificate template so that your directory domain controllers can request a certificate to enable LDAPS for your directory.
Step 3: Create a certificate template
In this step, you create a certificate template with server authentication and autoenrollment enabled on SubordinateCA. You create this new template (in this case, ServerAuthentication) by duplicating an existing certificate template (in this case, Domain Controller template) and adding server authentication and autoenrollment to the template.
Follow these steps to create a certificate template:
- Log in to SubordinateCA as CAAdmin.
- Launch Microsoft Windows Server Manager. Select Tools > Certification Authority.
- In the Certificate Authority window, expand the SubordinateCA tree in the left pane. Right-click Certificate Templates, and choose Manage.
- In the Certificate Templates Console window, right-click Domain Controller and choose Duplicate Template.
- In the Properties of New Template window, switch to the General tab and change the Template display name to ServerAuthentication.
- Switch to the Security tab, and choose Domain Controllers in the Group or user names section. Select the Allow check box for Autoenroll in the Permissions for Domain Controllers section.
- Switch to the Extensions tab, choose Application Policies in the Extensions included in this template section, and choose Edit
- In the Edit Application Policies Extension window, choose Client Authentication and choose Remove. Choose OK to create the ServerAuthentication certificate template. Close the Certificate Templates Console window.
- In the Certificate Authority window, right-click Certificate Templates, and choose New > Certificate Template to Issue.
- In the Enable Certificate Templates window, choose ServerAuthentication and choose OK.
You have finished creating a certificate template with server authentication and autoenrollment enabled on SubordinateCA. Your AWS Microsoft AD directory domain controllers can now obtain a certificate through autoenrollment to enable LDAPS.
Step 4: Configure AWS security group rules
In this step, you configure AWS security group rules so that your directory domain controllers can connect to the subordinate CA to request a certificate. To do this, you must add outbound rules to your directory’s AWS security group (in this case, sg-4ba7682d) to allow all outbound traffic to SubordinateCA’s AWS security group (in this case, sg-6fbe7109) so that your directory domain controllers can connect to SubordinateCA for requesting a certificate. You also must add inbound rules to SubordinateCA’s AWS security group to allow all incoming traffic from your directory’s AWS security group so that the subordinate CA can accept incoming traffic from your directory domain controllers.
Follow these steps to configure AWS security group rules:
- Log in to the Management instance as Admin.
- Navigate to the EC2 console.
- In the left pane, choose Network & Security > Security Groups.
- In the right pane, choose the AWS security group (in this case, sg-6fbe7109) of SubordinateCA.
- Switch to the Inbound tab and choose Edit.
- Choose Add Rule. Choose All traffic for Type and Custom for Source. Enter your directory’s AWS security group (in this case, sg-4ba7682d) in the Source box. Choose Save.
- Now choose the AWS security group (in this case, sg-4ba7682d) of your AWS Microsoft AD directory, switch to the Outbound tab, and choose Edit.
- Choose Add Rule. Choose All traffic for Type and Custom for Destination. Enter your directory’s AWS security group (in this case, sg-6fbe7109) in the Destination box. Choose Save.
You have completed the configuration of AWS security group rules to allow traffic between your directory domain controllers and SubordinateCA.
Step 5: AWS Microsoft AD enables LDAPS
The AWS Microsoft AD domain controllers perform this step automatically by recognizing the published template and requesting a certificate from the subordinate Microsoft enterprise CA. The subordinate CA can take up to 180 minutes to issue certificates to the directory domain controllers. The directory imports these certificates into the directory domain controllers and enables LDAPS for your directory automatically. This completes the setup of LDAPS for the AWS Microsoft AD directory. The LDAP service on the directory is now ready to accept LDAPS connections!
Step 6: Test LDAPS access by using the LDP tool
In this step, you test the LDAPS connection to the AWS Microsoft AD directory by using the LDP tool. The LDP tool is available on the Management machine where you installed Active Directory Administration Tools. Before you test the LDAPS connection, you must wait up to 180 minutes for the subordinate CA to issue a certificate to your directory domain controllers.
To test LDAPS, you connect to one of the domain controllers using port 636. Here are the steps to test the LDAPS connection:
- Log in to Management as Admin.
- Launch the Microsoft Windows Server Manager on Management and navigate to Tools > Active Directory Users and Computers.
- Switch to the tree view and navigate to corp.example.com > CORP > Domain Controllers. In the right pane, right-click on one of the domain controllers and choose Properties. Copy the DNS name of the domain controller.
- Launch the LDP.exe tool by launching Windows PowerShell and running the LDP.exe command.
- In the LDP tool, choose Connection > Connect.
- In the Server box, paste the DNS name you copied in the previous step. Type 636 in the Port box. Choose OK to test the LDAPS connection to port 636 of your directory.
- You should see the following message to confirm that your LDAPS connection is now open.
You have completed the setup of LDAPS for your AWS Microsoft AD directory! You can now encrypt LDAP communications between your Windows and Linux applications and your AWS Microsoft AD directory using LDAPS.
In this blog post, I walked through the process of enabling LDAPS for your AWS Microsoft AD directory. Enabling LDAPS helps you protect PII and other sensitive information exchanged over untrusted networks between your Windows and Linux applications and your AWS Microsoft AD. To learn more about how to use AWS Microsoft AD, see the Directory Service documentation. For general information and pricing, see the Directory Service home page.
If you have comments about this blog post, submit a comment in the “Comments” section below. If you have implementation or troubleshooting questions, start a new thread on the Directory Service forum.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/09/iso_rejects_nsa.html
A number of them voiced their distrust in emails to one another, seen by Reuters, and in written comments that are part of the process. The suspicions stem largely from internal NSA documents disclosed by Snowden that showed the agency had previously plotted to manipulate standards and promote technology it could penetrate. Budget documents, for example, sought funding to “insert vulnerabilities into commercial encryption systems.”
More than a dozen of the experts involved in the approval process for Simon and Speck feared that if the NSA was able to crack the encryption techniques, it would gain a “back door” into coded transmissions, according to the interviews and emails and other documents seen by Reuters.
“I don’t trust the designers,” Israeli delegate Orr Dunkelman, a computer science professor at the University of Haifa, told Reuters, citing Snowden’s papers. “There are quite a lot of people in NSA who think their job is to subvert standards. My job is to secure standards.”
I don’t trust the NSA, either.
Post Syndicated from Cameron Worrell original https://aws.amazon.com/blogs/security/how-to-configure-an-ldaps-endpoint-for-simple-ad/
Simple AD, which is powered by Samba 4, supports basic Active Directory (AD) authentication features such as users, groups, and the ability to join domains. Simple AD also includes an integrated Lightweight Directory Access Protocol (LDAP) server. LDAP is a standard application protocol for the access and management of directory information. You can use the BIND operation from Simple AD to authenticate LDAP client sessions. This makes LDAP a common choice for centralized authentication and authorization for services such as Secure Shell (SSH), client-based virtual private networks (VPNs), and many other applications. Authentication, the process of confirming the identity of a principal, typically involves the transmission of highly sensitive information such as user names and passwords. To protect this information in transit over untrusted networks, companies often require encryption as part of their information security strategy.
In this blog post, we show you how to configure an LDAPS (LDAP over SSL/TLS) encrypted endpoint for Simple AD so that you can extend Simple AD over untrusted networks. Our solution uses Elastic Load Balancing (ELB) to send decrypted LDAP traffic to HAProxy running on Amazon EC2, which then sends the traffic to Simple AD. ELB offers integrated certificate management, SSL/TLS termination, and the ability to use a scalable EC2 backend to process decrypted traffic. ELB also tightly integrates with Amazon Route 53, enabling you to use a custom domain for the LDAPS endpoint. The solution needs the intermediate HAProxy layer because ELB can direct traffic only to EC2 instances. To simplify testing and deployment, we have provided an AWS CloudFormation template to provision the ELB and HAProxy layers.
This post assumes that you have an understanding of concepts such as Amazon Virtual Private Cloud (VPC) and its components, including subnets, routing, Internet and network address translation (NAT) gateways, DNS, and security groups. You should also be familiar with launching EC2 instances and logging in to them with SSH. If needed, you should familiarize yourself with these concepts and review the solution overview and prerequisites in the next section before proceeding with the deployment.
Note: This solution is intended for use by clients requiring an LDAPS endpoint only. If your requirements extend beyond this, you should consider accessing the Simple AD servers directly or by using AWS Directory Service for Microsoft AD.
The following diagram and description illustrates and explains the Simple AD LDAPS environment. The CloudFormation template creates the items designated by the bracket (internal ELB load balancer and two HAProxy nodes configured in an Auto Scaling group).
Here is how the solution works, as shown in the preceding numbered diagram:
- The LDAP client sends an LDAPS request to ELB on TCP port 636.
- ELB terminates the SSL/TLS session and decrypts the traffic using a certificate. ELB sends the decrypted LDAP traffic to the EC2 instances running HAProxy on TCP port 389.
- The HAProxy servers forward the LDAP request to the Simple AD servers listening on TCP port 389 in a fixed Auto Scaling group configuration.
- The Simple AD servers send an LDAP response through the HAProxy layer to ELB. ELB encrypts the response and sends it to the client.
Note: Amazon VPC prevents a third party from intercepting traffic within the VPC. Because of this, the VPC protects the decrypted traffic between ELB and HAProxy and between HAProxy and Simple AD. The ELB encryption provides an additional layer of security for client connections and protects traffic coming from hosts outside the VPC.
- Our approach requires an Amazon VPC with two public and two private subnets. The previous diagram illustrates the environment’s VPC requirements. If you do not yet have these components in place, follow these guidelines for setting up a sample environment:
- Identify a region that supports Simple AD, ELB, and NAT gateways. The NAT gateways are used with an Internet gateway to allow the HAProxy instances to access the internet to perform their required configuration. You also need to identify the two Availability Zones in that region for use by Simple AD. You will supply these Availability Zones as parameters to the CloudFormation template later in this process.
- Create or choose an Amazon VPC in the region you chose. In order to use Route 53 to resolve the LDAPS endpoint, make sure you enable DNS support within your VPC. Create an Internet gateway and attach it to the VPC, which will be used by the NAT gateways to access the internet.
- Create a route table with a default route to the Internet gateway. Create two NAT gateways, one per Availability Zone in your public subnets to provide additional resiliency across the Availability Zones. Together, the routing table, the NAT gateways, and the Internet gateway enable the HAProxy instances to access the internet.
- Create two private routing tables, one per Availability Zone. Create two private subnets, one per Availability Zone. The dual routing tables and subnets allow for a higher level of redundancy. Add each subnet to the routing table in the same Availability Zone. Add a default route in each routing table to the NAT gateway in the same Availability Zone. The Simple AD servers use subnets that you create.
- The LDAP service requires a DNS domain that resolves within your VPC and from your LDAP clients. If you do not have an existing DNS domain, follow the steps to create a private hosted zone and associate it with your VPC. To avoid encryption protocol errors, you must ensure that the DNS domain name is consistent across your Route 53 zone and in the SSL/TLS certificate (see Step 2 in the “Solution deployment” section).
- Make sure you have completed the Simple AD Prerequisites.
- We will use a self-signed certificate for ELB to perform SSL/TLS decryption. You can use a certificate issued by your preferred certificate authority or a certificate issued by AWS Certificate Manager (ACM).
Note: To prevent unauthorized connections directly to your Simple AD servers, you can modify the Simple AD security group on port 389 to block traffic from locations outside of the Simple AD VPC. You can find the security group in the EC2 console by creating a search filter for your Simple AD directory ID. It is also important to allow the Simple AD servers to communicate with each other as shown on Simple AD Prerequisites.
This solution includes five main parts:
- Create a Simple AD directory.
- Create a certificate.
- Create the ELB and HAProxy layers by using the supplied CloudFormation template.
- Create a Route 53 record.
- Test LDAPS access using an Amazon Linux client.
1. Create a Simple AD directory
With the prerequisites completed, you will create a Simple AD directory in your private VPC subnets:
- In the Directory Service console navigation pane, choose Directories and then choose Set up directory.
- Choose Simple AD.
- Provide the following information:
- Directory DNS – The fully qualified domain name (FQDN) of the directory, such as corp.example.com. You will use the FQDN as part of the testing procedure.
- NetBIOS name – The short name for the directory, such as CORP.
- Administrator password – The password for the directory administrator. The directory creation process creates an administrator account with the user name Administrator and this password. Do not lose this password because it is nonrecoverable. You also need this password for testing LDAPS access in a later step.
- Description – An optional description for the directory.
- Directory Size – The size of the directory.
- Provide the following information in the VPC Details section, and then choose Next Step:
- VPC – Specify the VPC in which to install the directory.
- Subnets – Choose two private subnets for the directory servers. The two subnets must be in different Availability Zones. Make a note of the VPC and subnet IDs for use as CloudFormation input parameters. In the following example, the Availability Zones are us-east-1a and us-east-1c.
- Review the directory information and make any necessary changes. When the information is correct, choose Create Simple AD.
It takes several minutes to create the directory. From the AWS Directory Service console , refresh the screen periodically and wait until the directory Status value changes to Active before continuing. Choose your Simple AD directory and note the two IP addresses in the DNS address section. You will enter them when you run the CloudFormation template later.
Note: Full administration of your Simple AD implementation is out of scope for this blog post. See the documentation to add users, groups, or instances to your directory. Also see the previous blog post, How to Manage Identities in Simple AD Directories.
2. Create a certificate
In the previous step, you created the Simple AD directory. Next, you will generate a self-signed SSL/TLS certificate using OpenSSL. You will use the certificate with ELB to secure the LDAPS endpoint. OpenSSL is a standard, open source library that supports a wide range of cryptographic functions, including the creation and signing of x509 certificates. You then import the certificate into ACM that is integrated with ELB.
- You must have a system with OpenSSL installed to complete this step. If you do not have OpenSSL, you can install it on Amazon Linux by running the command, sudo yum install openssl. If you do not have access to an Amazon Linux instance you can create one with SSH access enabled to proceed with this step. Run the command, openssl version, at the command line to see if you already have OpenSSL installed.
- Create a private key using the command, openssl genrsa command.
- Generate a certificate signing request (CSR) using the openssl req command. Provide the requested information for each field. The Common Name is the FQDN for your LDAPS endpoint (for example, ldap.corp.example.com). The Common Name must use the domain name you will later register in Route 53. You will encounter certificate errors if the names do not match.
- Use the openssl x509 command to sign the certificate. The following example uses the private key from the previous step (privatekey.pem) and the signing request (server.csr) to create a public certificate named server.crt that is valid for 365 days. This certificate must be updated within 365 days to avoid disruption of LDAPS functionality.
- You should see three files: privatekey.pem, server.crt, and server.csr.
Restrict access to the private key.
Keep the private key and public certificate for later use. You can discard the signing request because you are using a self-signed certificate and not using a Certificate Authority. Always store the private key in a secure location and avoid adding it to your source code.
- In the ACM console, choose Import a certificate.
- Using your favorite Linux text editor, paste the contents of your server.crt file in the Certificate body box.
- Using your favorite Linux text editor, paste the contents of your privatekey.pem file in the Certificate private key box. For a self-signed certificate, you can leave the Certificate chain box blank.
- Choose Review and import. Confirm the information and choose Import.
3. Create the ELB and HAProxy layers by using the supplied CloudFormation template
Now that you have created your Simple AD directory and SSL/TLS certificate, you are ready to use the CloudFormation template to create the ELB and HAProxy layers.
- Load the supplied CloudFormation template to deploy an internal ELB and two HAProxy EC2 instances into a fixed Auto Scaling group. After you load the template, provide the following input parameters. Note: You can find the parameters relating to your Simple AD from the directory details page by choosing your Simple AD in the Directory Service console.
|Input parameter||Input parameter description|
|HAProxyInstanceSize||The EC2 instance size for HAProxy servers. The default size is t2.micro and can scale up for large Simple AD environments.|
|MyKeyPair||The SSH key pair for EC2 instances. If you do not have an existing key pair, you must create one.|
|VPCId||The target VPC for this solution. Must be in the VPC where you deployed Simple AD and is available in your Simple AD directory details page.|
|SubnetId1||The Simple AD primary subnet. This information is available in your Simple AD directory details page.|
|SubnetId2||The Simple AD secondary subnet. This information is available in your Simple AD directory details page.|
|MyTrustedNetwork||Trusted network Classless Inter-Domain Routing (CIDR) to allow connections to the LDAPS endpoint. For example, use the VPC CIDR to allow clients in the VPC to connect.|
|SimpleADPriIP||The primary Simple AD Server IP. This information is available in your Simple AD directory details page.|
|SimpleADSecIP||The secondary Simple AD Server IP. This information is available in your Simple AD directory details page.|
|LDAPSCertificateARN||The Amazon Resource Name (ARN) for the SSL certificate. This information is available in the ACM console.|
- Enter the input parameters and choose Next.
- On the Options page, accept the defaults and choose Next.
- On the Review page, confirm the details and choose Create. The stack will be created in approximately 5 minutes.
4. Create a Route 53 record
The next step is to create a Route 53 record in your private hosted zone so that clients can resolve your LDAPS endpoint.
- If you do not have an existing DNS domain for use with LDAP, create a private hosted zone and associate it with your VPC. The hosted zone name should be consistent with your Simple AD (for example, corp.example.com).
- When the CloudFormation stack is in CREATE_COMPLETE status, locate the value of the LDAPSURL on the Outputs tab of the stack. Copy this value for use in the next step.
- On the Route 53 console, choose Hosted Zones and then choose the zone you used for the Common Name box for your self-signed certificate. Choose Create Record Set and enter the following information:
- Name – The label of the record (such as ldap).
- Type – Leave as A – IPv4 address.
- Alias – Choose Yes.
- Alias Target – Paste the value of the LDAPSURL on the Outputs tab of the stack.
- Leave the defaults for Routing Policy and Evaluate Target Health, and choose Create.
5. Test LDAPS access using an Amazon Linux client
At this point, you have configured your LDAPS endpoint and now you can test it from an Amazon Linux client.
- Create an Amazon Linux instance with SSH access enabled to test the solution. Launch the instance into one of the public subnets in your VPC. Make sure the IP assigned to the instance is in the trusted IP range you specified in the CloudFormation parameter MyTrustedNetwork in Step 3.b.
- SSH into the instance and complete the following steps to verify access.
- Install the openldap-clients package and any required dependencies:
sudo yum install -y openldap-clients.
- Add the server.crt file to the /etc/openldap/certs/ directory so that the LDAPS client will trust your SSL/TLS certificate. You can copy the file using Secure Copy (SCP) or create it using a text editor.
- Edit the /etc/openldap/ldap.conf file and define the environment variables BASE, URI, and TLS_CACERT.
- The value for BASE should match the configuration of the Simple AD directory name.
- The value for URI should match your DNS alias.
- The value for TLS_CACERT is the path to your public certificate.
- Install the openldap-clients package and any required dependencies:
Here is an example of the contents of the file.
To test the solution, query the directory through the LDAPS endpoint, as shown in the following command. Replace corp.example.com with your domain name and use the Administrator password that you configured with the Simple AD directory
You should see a response similar to the following response, which provides the directory information in LDAP Data Interchange Format (LDIF) for the administrator distinguished name (DN) from your Simple AD LDAP server.
You can now use the LDAPS endpoint for directory operations and authentication within your environment. If you would like to learn more about how to interact with your LDAPS endpoint within a Linux environment, here are a few resources to get started:
- Using ldapsearch to locate and retrieve directory entries
- Using ldapmodify to make changes to directory entries
- Managing access with the System Security Services Daemon (SSSD) – SSSD can be used within a Linux environment to authenticate LDAP sessions.
If you receive an error such as the following error when issuing the ldapsearch command, there are a few things you can do to help identify issues.
- You might be able to obtain additional error details by adding the -d1 debug flag to the ldapsearch command in the previous section.
- Verify that the parameters in ldap.conf match your configured LDAPS URI endpoint and that all parameters can be resolved by DNS. You can use the following dig command, substituting your configured endpoint DNS name.
- Confirm that the client instance from which you are connecting is in the CIDR range of the CloudFormation parameter, MyTrustedNetwork.
- Confirm that the path to your public SSL/TLS certificate configured in ldap.conf as TLS_CAERT is correct. You configured this in Step 5.b.3. You can check your SSL/TLS connection with the command, substituting your configured endpoint DNS name for the string after –connect.
- Verify that your HAProxy instances have the status InService in the EC2 console: Choose Load Balancers under Load Balancing in the navigation pane, highlight your LDAPS load balancer, and then choose the Instances
You can use ELB and HAProxy to provide an LDAPS endpoint for Simple AD and transport sensitive authentication information over untrusted networks. You can explore using LDAPS to authenticate SSH users or integrate with other software solutions that support LDAP authentication. This solution’s CloudFormation template is available on GitHub.
If you have comments about this post, submit them in the “Comments” section below. If you have questions about or issues implementing this solution, start a new thread on the Directory Service forum.
– Cameron and Jeff
Post Syndicated from Andy original https://torrentfreak.com/eset-tries-to-scare-people-away-from-using-torrents-170805/
Sellers of CCTV equipment, for example, would have us believe that criminals don’t want to be photographed and will often go elsewhere in the face of that. Car alarm companies warn us that since X thousand cars are stolen every minute, an expensive Immobilizer is an anti-theft must.
Of course, they’re absolutely right to point these things out. People want to know about these offline risks since they affect our quality of life. The same can be said of those that occur in the online world too.
We ARE all at risk of horrible malware that will trash our computers and steal our banking information so we should all be running adequate protection. That being said, how many times do our anti-virus programs actually trap a piece of nasty-ware in a year? Once? Twice? Ten times? Almost never?
The truth is we all need to be informed but it should be done in a measured way. That’s why an article just published by security firm ESET on the subject of torrents strikes a couple of bad chords, particularly with people who like torrents. It’s titled “Why you should view torrents as a threat” and predictably proceeds to outline why.
“Despite their popularity among users, torrents are very risky ‘business’,” it begins.
“Apart from the obvious legal trouble you could face for violating the copyright of musicians, filmmakers or software developers, there are security issues linked to downloading them that could put you or your computer in the crosshairs of the black hats.”
Aside from the use of the phrase “very risky” (‘some risk’ is a better description), there’s probably very little to complain about in this opening shot. However, things soon go downhill.
“Merely downloading the newest version of BitTorrent clients – software necessary for any user who wants to download or seed files from this ‘ecosystem’ – could infect your machine and irreversibly damage your files,” ESET writes.
Following that scary statement, some readers will have already vowed never to use a torrent again and moved on without reading any more, but the details are really important.
To support its claim, ESET points to two incidents in 2016 (which to its great credit the company actually discovered) which involved the Transmission torrent client. Both involved deliberate third-party infection and in the latter hackers attacked Transmission’s servers and embedded malware in its OSX client before distribution to the public.
No doubt these were both miserable incidents (to which the Transmission team quickly responded) but to characterize this as a torrent client problem seems somewhat unfair.
People intent on spreading viruses and malware do not discriminate and will happily infect ANY piece of computer software they can. Sadly, many non-technical people reading the ESET post won’t read beyond the claim that installing torrent clients can “infect your machine and irreversibly damage your files.”
That’s a huge disservice to the hundreds of millions of torrent client installations that have taken place over a decade and a half and were absolutely trouble free. On a similar basis, we could argue that installing Windows is the main initial problem for people getting viruses from the Internet. It’s true but it’s also not the full picture.
Finally, the piece goes on to detail other incidents over the years where torrents have been found to contain malware. The several cases highlighted by ESET are both real and pretty unpleasant for victims but the important thing to note here is torrent users are no different to any other online user, no matter how they use the Internet.
People who download files from the Internet, from ALL untrusted sources, are putting themselves at risk of getting a virus or other malware. Whether that content is obtained from a website or a P2P network, the risks are ever-present and only a foolish person would do so without decent security software (such as ESET’s) protecting them.
The take home point here is to be aware of security risks and put them into perspective. It’s hard to put a percentage on these things but of the hundreds of millions of torrent and torrent client downloads that have taken place since their inception 15 years ago, the overwhelming majority have been absolutely fine.
Security situations do arise and we need to be aware of them, but presenting things in a way that spreads unnecessary concern in a particular sector isn’t necessary to sell products.
The AV-TEST Institute registers around 390,000 new malicious programs every day that don’t involve torrents, plenty for any anti-virus firm to deal with.
Post Syndicated from Ernesto original https://torrentfreak.com/court-warner-bros-needs-stronger-evidence-against-alleged-bittorrent-pirate-170718/
Over the past decade, copyright holders have gone after hundreds of thousands of alleged pirates in Germany, demanding settlements ranging from a few hundred to thousands of euros.
The targeted account holders are often indeed the perpetrator, but false accusations are bound to happen due to the sheer volume of these cases.
This is one of the reasons why local courts are paying careful attention to the provided evidence. At the District Court of Cologne, this recently resulted in a verdict, clarifying that simply linking an IP-address to a pirated download is not good enough.
The case in question deals with a claim from the local branch of Warner Bros. Entertainment, which accused an account holder of sharing a pirated episode of the popular TV-show “Person of Interest.”
The Hollywood studio claimed 500 euros in damages from the alleged copyright infringer, as well as 168.50 euros in expenses. The defendant, however, said he was innocent, refused to pay up, and contested the claim in court, with success.
Warner’s tracking partner Ipoque had only monitored the defendant’s IP-address twice during a period of 10 minutes. This is not good enough according to the court, since IP-address misassignments regularly take place.
“The causes for a misassignment don’t have to relate to the software of the tracking company, they can also come from others. For example, the transmission of acquired data, or the ISPs assignment of collected IP addresses to connection holders. In the latter case, the Court of First Instance has seen an error rate of at least 2 – 3%,” the court writes.
In this case, the defendant argued that his ISP failed to update the IP-address assignments and that he no longer used the infringing address at the contested time.
The District Court of Cologne agreed that this was a plausible argument. Ideally, Warner should have provided a more extensive tracking record, with more IP-addresses leading to the same account holder, assuming that the assignments regularly change.
Defense attorney Christian Solmecke tells TorrentFreak that so-called “simple tracking,” where only a single IP-address is used as evidence, is simply not good enough.
“In case of simple tracking, evaluation errors are always possible. For instance, mixing up the numbers of the IP-address. The tracking parameters are technically complicated so errors may occur at various stages of the process,” Solmecke notes.
In some cases the error rates can go up to 50%, a recent verdict has shown, which means that accused file-sharers have a solid defense when they are accused based on minimal evidence.
“This is important for defendants as courts usually tend to assume that it cannot be sufficiently clarified whether filesharing did indeed occur via the Internet connection of the defendant. Simple tracking can, therefore, be seen as a good chance for defendants to win against the warning letter industry,” Solmecke adds.
While the verdict is unlikely to stop the piracy settlement industry in Germany, it may prompt rightsholders to step up their BitTorrent monitoring practices.
This doesn’t only apply to Warner Bros. Entertainment, but also to other major rightsholders including the local branches of Universal Pictures, Twentieth Century Fox, Universal Music, EMI Music and Sony Music, which are all active on the anti-piracy front in Germany.
The full verdict of the District Court of Cologne is available Tarnkappe.
Post Syndicated from Darknet original http://feedproxy.google.com/~r/darknethackers/~3/_VMH_YXZiYs/
OpenPuff is a professional steganography tool, with unique features you won’t find among any other free or commercial software. OpenPuff is 100% free and suitable for highly sensitive data covert transmission. The tool contains deniable steganography, carrier chains, unique layers of security and obfuscation, multiple carrier formats, is portable…
Read the full post at darknet.org.uk
Post Syndicated from Ernesto original https://torrentfreak.com/hardware-provider-is-liable-for-live-streaming-piracy-court-rules-170529/
While ‘pirate’ sports streaming sites have been around for over a decade, in recent years rightsholders have taken a more aggressive stance.
The UK Premier League has triggered several police investigations, for example, which have led to the shutdown of several streaming platforms.
In Germany, the local football league (DFL) and Sky Deutschland are involved in a similar battle. The rightsholder and broadcaster feel that unauthorized streaming sites threaten their livelihoods so they’ve initiated legal action in response.
One of the prime targets of these efforts was the streaming portal Stream4u.tv, which was broadcasting sports events without permission. In addition to the site’s operator, a civil lawsuit filed by Sky also targeted the hardware provider that offered the equipment used to decrypt and distribute the streaming signal.
Last week Sky declared a major victory after The District Court of Hamburg ruled that both the site operator and hardware provider are liable for copyright infringement.
Together, both defendants must now pay €18,000 in damages. A clear win for Sky, especially since the streaming portal has been shut down as well.
Aside from the damages, Sky highlights that this is the first time that a third-party intermediary has been held liable for copyright infringement in a case like this. They hope the result will send a strong deterrent message to others.
According to Sky, the ruling effectively means that every technical service provider faces a significant liability risk if they are aware of the illegal use of its services and do not immediately address legitimate complaints.
“The ruling is a warning for all those involved in the illegal distribution of Sky content,” says Thomas Stahn, Director Anti-Piracy & Technology at Sky Deutschland, commenting on the case.
“In contrast to criminal law, every helper is also liable for the full damages suffered by the injured parties – regardless of whether or not it profited from the illegal business,” he adds.
Sky informs TorrentFreak that the Stream4u.tv operator was not present at the court hearings, only the hardware provider. The company could not provide any additional details on the provider but noted that the hardware itself is not illegal.
“The hardware in question was used to receive the Sky broadcast signal and encode it for transmission via the internet. The hardware itself is not illegal in general,” a Sky spokesperson told us.
This isn’t the first victory of its kind for the German division of Sky. As Tarnkappe points out, late last year two people were convicted for their involvement with a sports streaming platform, resulting in a prison sentence for one of them.
Sky Deutschland has several criminal and civil copyright cases pending in Germany, so this isn’t likely to be the last verdict we’ll see against sports streaming sites and services.