Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Quincy Larson, Medium, 16 Mar 2017
<https://medium.freecodecamp.com/inside-the-invisible-war-for-the-open-internet-dd31a29a3f08>
There are a lot of scary things happening these days, but here's what keeps
me up late at night. A handful of corporations are turning our open Internet
into this:
These corporations want to lock down the Internet and give us access to
nothing more than a few walled gardens. They want to burn down the Library
of Alexandria and replace it with a magazine rack.
Why? Because they'll make more money that way.
This may sound like a conspiracy theory, but this process is moving forward
at an alarming rate.
History is repeating itself.
So far, the story of the Internet has followed the same tragic narrative
that's befallen other information technologies over the past 160 years:
* the telegram
* the telephone
* cinema
* radio
* television
Each of these had roughly the same story arc:
* Inventors discovered the technology.
* Hobbyists pioneered the applications of that technology, and
popularized it.
* Corporations took notice. They commercialized the technology,
refined it, and scaled it.
* Once the corporations were powerful enough, they tricked the government
into helping them lock the technology down. They installed themselves
as natural monopolies.
* After a long period of stagnation, a new technology emerged to disrupt
the old one. Sometimes this would dislodging the old monopoly. But
sometimes it would only further solidify them.
This loop has repeated itself so many times that Tim Wu (the Harvard law
professor who coined the term Net Neutrality) has a name for it: The Cycle.
“History shows a typical progression of information technologies, from
somebody's hobby to somebody's industry; from jury-rigged contraption to
slick production marvel; from a freely accessible channel to one strictly
controlled by a single corporation or cartel—from open to closed
system.''
And right now, we're in step 4 the open Internet's narrative. We're
surrounded by monopolies.
The problem is that we've been in step 4 for decades now. And there's no
step 5 in sight. The creative destruction that the Economist Joseph
Schumpeter first observed in the early 1900s has yet to materialize.
The Internet, it seems, is special. It's the ultimate information technology
-- capable of supplanting the telegram, telephone, radio, cinema,
television, and much more—and there's no clear way to disrupt it.
But the war for the commanding heights of the Internet is far from over.
There are many players on this global chess board. Governments. Telecom
monopolies. Internet giants like Google and Facebook. NGOs. Startups.
Hackers. And—most importantly—you.
"On the better web Berners-Lee envisions, users control where their data is stored and how it's accessed. For example, social networks would still run in the cloud. But you could store your data locally. Alternately, you could choose a different cloud server run by a company or community you trust. You might have different servers for different types of information -— for health and fitness data, say -— that is completely separate from the one you use for financial records." https://www.wired.com/2017/04/tim-berners-lee-inventor-web-plots-radical-overhaul-creation/ [Dave Farber noted a related BBC item: Web inventor Sir Tim Berners-Lee slams UK and US net plans] http://www.bbc.com/news/technology-39490324
D. Victoria Baranetsky, JIPEL <http://jipel.law.nyu.edu/>, 3 Apr 2017 Encryption and the Press Clause The NYU Journal of Intellectual Property & Entertainment Law JIPEL Vol. 6 – No. 2 http://jipel.law.nyu.edu/vol-6-no-2-1-baranetsky/ Almost twenty years ago, a hostile debate over whether government could regulate encryption—later named the Crypto Wars—seized the country. At the center of this debate stirred one simple question: is encryption protected speech? This issue touched all branches of government percolating from Congress, to the President, and eventually to the federal courts. In a waterfall of cases, several United States Court of Appeals appeared to reach a consensus that encryption was protected speech under the First Amendment, and with that the Crypto Wars appeared to be over, until now. Nearly twenty years later, the Crypto Wars have returned. Following recent mass shootings, law enforcement has once again questioned the legal protection for encryption and tried to implement backdoor techniques to access messages sent over encrypted channels. In the case, Apple v. FBI, the agency tried to compel Apple to grant access to the iPhone of a San Bernardino shooter. The case was never decided, but the legal arguments briefed before the court were essentially the same as they were two decades prior. Apple and amici supporting the company argued that encryption was protected speech. While these arguments remain convincing, circumstances have changed in ways that should be reflected in the legal doctrines that lawyers use. Unlike twenty years ago, today surveillance is ubiquitous, and the need for encryption is no longer felt by a seldom few. Encryption has become necessary for even the most basic exchange of information given that most Americans share “nearly every aspect of their lives—from the mundane to the intimate'' over the Internet, as stated in a recent Supreme Court opinion.* Given these developments, lawyers might consider a new justification under the Press Clause. In addition to the many doctrinal concerns that exist with protection under the Speech Clause, the Press Clause is normatively and descriptively more accurate at protecting encryption as a tool for secure communication without fear of government surveillance. This Article outlines that framework by examining the historical and theoretical transformation of the Press Clause since its inception. * Riley v. California, 134 S. Ct. 2473, 2490 (2014).
'Trust no one': Modernization, paranoia, and conspiracy culture Stef Aupers, Erasmus University, The Netherlands European Journal of Communication 27(1) 22-34, 2012 http://journals.sagepub.com/doi/pdf/10.1177/0267323111433566 Abstract Popular conspiracy theories, like those about JFK, the attacks of 9/11, the death of Princess Diana or the swine flu vaccination, are generally depicted in the social sciences as pathological, irrational and, essentially, anti-modern. In this contribution it is instead argued that conspiracy culture is a radical and generalized manifestation of distrust that is embedded in the cultural logic of modernity and, ultimately, produced by processes of modernization. In particular, epistemological doubts about the validity of scientific knowledge claims, ontological insecurity about rationalized social systems like the state, multinationals, and the media; and a relentless 'will to believe' in a disenchanted world—already acknowledged by Adorno, Durkheim, Marx, and Weber—nowadays motivate a massive turn to conspiracy culture in the West. [Thanks to Dan Geer for spotting this one. PGN]
NNSquad http://www.slate.com/articles/technology/future_tense/2017/04/russia_is_trying_to_copy_china_s_internet_censorship.html This is part of a larger story. Just a few years ago, Russians had a mostly free Internet. Now, Russian authorities would like to imitate China's model of Internet control. They are unlikely to succeed. The Kremlin will find that once you give people Internet freedom, it's not so easy to completely take it away.
https://www.wired.com/2017/04/russian-hackers-used-backdoor-two-decades/
https://www.wired.com/2017/03/russian-hacker-spy-botnet
When WikiLeaks founder Julian Assange disclosed earlier this month that his anti-secrecy group had obtained CIA tools for hacking into technology products made by U.S. companies, security engineers at Cisco Systems (CSCO.O) swung into action. The Wikileaks documents described how the Central Intelligence Agency had learned more than a year ago how to exploit flaws in Cisco's widely used Internet switches, which direct electronic traffic, to enable eavesdropping. Senior Cisco managers immediately reassigned staff from other projects to figure out how the CIA hacking tricks worked, so they could help customers patch their systems and prevent criminal hackers or spies from using the same methods, three employees told Reuters on condition of anonymity. The Cisco engineers worked around the clock for days to analyze the means of attack, create fixes, and craft a stopgap warning about a security risk affecting more than 300 different products, said the employees, who had direct knowledge of the effort. That a major U.S. company had to rely on WikiLeaks to learn about security problems well-known to U.S. intelligence agencies underscores concerns expressed by dozens of current and former U.S. intelligence and security officials about the government's approach to cybersecurity. http://mobile.reuters.com/article/idUSKBN17013U
http://www.governmentattic.org/ [FOIA = U.S. Freedom of Information Act]
The traditional model of hacking a bank isn't so different from the old-fashioned method of robbing one. Thieves get in, get the goods, and get out. But one enterprising group of hackers targeting a Brazilian bank seems to have taken a more comprehensive and devious approach: One weekend afternoon, they rerouted all of the bank's online customers to perfectly reconstructed fakes of the bank's properties, where the marks obediently handed over their account information. https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/ Gabriel Goldberg, Computers and Publishing, Inc. gabe@gabegold.com 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433
[This is the item reported by krebsonsecurity in RISKS-30.22, Why I always tug on the ATM. But it is clever enough that I'm happy to include Gabe's posting as well. PGN] Not so long ago, enterprising thieves who wanted to steal the entire contents of an ATM had to blow it up. Today, a more discreet sort of cash-machine burglar can walk away with an ATM's stash and leave behind only a tell-tale three-inch hole in its front panel. https://www.wired.com/2017/04/hackers-emptying-atms-drill-15-worth-gear/
Microsoft hasn't altered its earlier position, but it all seems a little harsh. http://www.pcworld.com/article/3181814/windows/microsoft-says-its-blocking-windows-7-8-patches-on-latest-amd-intel-chips.html
https://www.theatlantic.com/technology/archive/2017/04/garadget-sabotage/521937/
FYI—No, this isn't another April 1st joke or a SNL skit, because you just
can't make this stuff up.
"the early version of the Sky Viper [quadcopter drone] cam control app was
partly written by the same guys who wrote the dildo app code"
(Follow the link to see the console dumps and code snippets.)
https://www.pentestpartners.com/blog/vulnerable-wi-fi-dildo-camera-endoscope-yes-really/
Blog: Internet Of Things
Vulnerable Wi-Fi dildo camera endoscope. Yes really
Beau du Jour 03 Apr 2017
Sometimes, our jaws hit the floor. We see some pretty bad things in IoT
security, but this has to take the biscuit. After the WeVibe lawsuit and
settlement, we started looking at the security of IoT sex toys again.
A few questions:
* Is there any reason a vibrator should also be a Wi-Fi access point?
* What about a vibrator which has an endoscope camera in the end of it?
* Should that vibrator also contain hidden functionality to connect itself
to Skype?
* To save videos automatically to a network file share?
* Or send pictures in emails?
* What about if it has code injection in its web interface?
Well, that's the Svakom Siime Eye, a vibrator endoscope. Yes, this thing
exists.
It is a pretty normal, slightly awkwardly-shaped vibrator with a camera in
the end. It costs $250. But, more relevant than the novelty/enjoyment
value of the product and its price, is what it's running, how we hacked it,
and why it's an interesting case of another IoT device produced without much
care or attention.
First Impressions
The Siime Eye normal use-case is in conjunction with an iPhone or Android
app. You turn it on, connect to its AP (SSID "Siime Eye") with the default
password ("88888888"), open the app, then 'insert' it. The app itself is
limited: You can view the live video stream, take pictures or videos and
save them to your device. Everything you'd expect from a camera/vibrator, I
guess.
The Android app looks a bit like this:
With names like "wingedcamlib" and "skyviper", it looks a lot like libraries
in here were written with drones in mind.
We had a chat with the guys at Sky Viper (who make awesome drone cameras
BTW) who were as surprised as us to find their brand name in mobile app code
that runs an IoT dildo. They suspect that the early version of the Sky
Viper cam control app was partly written by the same guys who wrote the
dildo app code.
That's not everything we can get out of the app though: The "com.SiimeEye"
source includes some hard-coded credentials, and a hard-coded IP address and
port.
There's an account called "admin", with a blank password.
On connecting to the Siime Eye AP with a laptop, we can try the server at
192.168.1.1:80. An authentication box pops up, prompting for a username and
password.
It looks a lot like Basic authentication, and the admin:[blank] credentials
work.
So, it's trivial to connect to the AP and auth to the web interface.
Remember, the credentials are hard-coded in the official app, so any user
wanting to use the Siime Eye the official way will never change these
credentials. If you can get onto the wireless AP, you'll have instant
access to everything on this web application. It allows multiple concurrent
connections too, without any fuss at all.
THAT WEB APP SERVES THE VIDEO FROM THE CAMERA! OMG!
Oh, and being a Wi-Fi AP means you can find users too...
This part surprised us the most—using Wi-Fi is logical, given the
bandwidth required to stream video, but most IoT devices would be configured
to operate as a Wi-Fi client, not an access point. This choice was odd.
Geo-locating wireless vibrator users
Under normal use, the wireless AP name is also static. That means we can
query a wardriving site like wigle.net, and find locations where a "Siime
Eye" might be. Here's one seen in Tokyo:
That's bad enough, but what else could we do? Could we get a root shell and
persistence?
Software
The web application is designed for administering a much more
general-purpose camera, one attached to a drone, for example. We can do a
lot more here than the mobile app allows us to do.
There's some NFS settings, motion detection settings, and much more. As we
often see in embedded device web interfaces, all settings requests get
processed by an array of .cgi files. A lot of requests to change settings
are sent to /set_params.cgi. All it does is returns JSON data indicating
success or failure. Its sibling file, /get_params.cgi, sends back a lot of
configuration data in the response if you send it a GET request. This
includes parameters like "skype_pwd", "smtp_pwd", "ddns_pwd". From that, we
can assume that there's functionality in the Siime Eye to send emails,
change DNS settings, and even add a Skype account.
A typical response from one of the more banal .cgi files looks like this:
It seems like it's got a permissive Cross-Origin Resource Sharing (CORS)
policy, as it sends back the "Access-Control-Allow-Origin" header with a
wildcard value. In theory, this would let us, or any browser which has
access to this web application, read the contents of any response from the
server. The facility to read the response from another website is usually
restricted by browsers, and is an integral part of the "Same Origin Policy"
(SOP). It's a restriction which means that malicious websites can't just
arbitrarily read your bank balance.
Ideally, the SOP also means that an arbitrary site can't see and
subsequently siphon off your IP camera video stream. But if a server
specifies the "Access-Control-Allow-Origin" header with a wildcard value,
anyone from any website can read the response. It makes the SOP useless.
So, I wrote a quick piece of JavaScript using XMLHttpRequest calls to try to
siphon data off the device. However, weirdly, the browser kept complaining
about us breaking the SOP. That wasn't what I was expecting; it required
some investigation.
After some digging, I found out the problem. It turns out one of the
idiosyncrasies of CORS with XHR is that a pre-flight request with the
OPTIONS header is sent first, expecting the Access-Control-Allow-Origin
header in return. But, the Siime Eye interprets OPTIONS as a RTSP request
and we get a standard RTSP response.
So you can't siphon data off it that way because the browser thinks you're
breaking the SOP; it's not getting the response it expects. It also seems
that the RTSP protocol is running out of port 80 as well.
All the .cgi files, however, do allow you to specify a JSONP callback in
every request, which means SOP is still useless. JSONP lets you specify a
variable name, import the resulting JSON data as a script, and use it like
any other JSON data (https://en.wikipedia.org/wiki/JSONP).
So I wrote a small PoC to dump a load of information from the device using
JSONP, including a list of local Wi-Fi networks it can see, and the video
stream. The video stream is "protected", in that you have to negotiate a
token before you can view it. But using JSONP still means we can siphon it
off, with very little hassle. You can see my code here.
https://github.com/pentestpartners/siime_root
But, that can't be everything that's wrong with this. Time to start
Googling.
Hidden services
There wasn't anything too damning turning up just from some cursory poking
at the web interface. So, after some light googling of some .cgi filenames,
I came across the Reecam developer documentation
(http://wiki.reecam.cn/CGI/Params).
Every .cgi file I came across on the Siime Eye, seemed to be documented on
the Reecam site. The hardware MAC address points us towards Shenzhen Reecam
Tech Ltd. It's pretty safe to say the software running on the Siime Eye was
developed by them.
I wanted to find the firmware, to get a sense of what was actually happening
in the background. At this point I only had port 80 open, with a slightly
ropey but relatively robust-looking web interface. I trawled through lots
of developer info on their site but, despite a lot of digging, I couldn't
actually find the firmware anywhere.
However, one parameter documented on the site, which I didn't come across
while initially testing the web interface was "telnetd". Browsing to the
following link restarted the Siime Eye:
http://192.168.40.17/set_params.cgi?telnetd=1&save=1&reboot=1
When it came back up, telnet was available. This seems like an easy win.
Default Mirai credentials and we're in, right? Unfortunately it wasn't so
simple.
After hitting it with a wordlist for way too long, I gave up. Nothing
seemed to be working, and there were no clues online about what the password
might be.
So, I had no firmware, no shell, and only a minor web interface issue. The
next step had to be to dismantle it.
Hardware
The Siime runs off a Ralink RT5350F WiSoC which has a little MIPS processor
in it. It's often used in things like Wi-Fi extenders, and it's relatively
robust. It's also got Winbond W9825G6JH-6 SDRAM and a Winbond 25Q64FVSIG
flash chip, which holds the filesystem.
It also has some handy exposed UART pads, which are easy to clip onto. I
connected with a BusPirate, trial and error'd the baud rate to 57600, and
got a nice stream of useless debug info. I also got the same impenetrable
telnet login prompt, and a pretty restrictive uBoot shell.
No easy-wins here either. I decided it was worth trying to dump the
firmware. With some cheap eBay clips, a BusPirate, flashrom, and a Stanley
knife (to whittle down the cheap clips so they wouldn't nudge each other off
the chip), I managed to get a read off the Winbond 25Q64FVSIG chip.
The read took about 30mins, and gave a nice solid blob of firmware, which I
then binwalk'd out to a proper filesystem.
It was a Linux filesystem, predictably. But there was no /etc/passwd, not
/etc/shadow; and only traces of an assumedly unused boot script which
attempted to load parameters from (nonexistent) NVRAM. Lots of red herrings
and leftover scripts from previous incarnations of the Reecam firmware.
What I needed at this point was some sense of what was happening in the
system while it was running. Rather than just indiscriminately grep
everything "just in case", I wanted a more distilled sense of the system; I
still needed a shell.
A Hybrid Approach
We left the laptop clipped onto the UART, and started probing the web
interface again. This time, I noticed small debug messages from the web
application being directed to the UART stream. It looked a lot like stderr
and stdout might just be echoed out for debugging purposes.
I returned to the NFS settings page. "How else can you set up a Network
File Share other than by sending unsanitised parameters directly to the UNIX
'mount' command?", I thought.
A few minutes later, I found a command injection point, with all stdout and
stderr output getting sent to the UART stream on my other laptop.
Sending "192.168.1.1; ls -al; echo" and "192.168.1.1; cat /etc/passwd; echo"
as the "HOST/IP" parameter in the NFS settings resulted in mount errors, a
listing of the root filesystem and the contents of /etc/passwd.
Cracking the descrypt hash didn't go very well with a wordlist and light
brute-forcing. But, as the web application was running as root, I wrote
myself into /etc/passwd as another root user and logged in over telnet.
In the end, cracking the hash wasn't even needed. I checked out the running
processes and honed in on some custom system binaries: /bin/reecam and
/bin/camera.
Running strings on /bin/camera from the firmware dumped earlier, and
grepping for "root" spat out the hardcoded telnet password.
It's the slightly—but not entirely—secure: reecam4debug.
>From here's it's plain sailing. We've got complete control over every
inbuilt function in the Siime Eye, easy access to the video stream, a root
shell and persistence on a dildo.
Video overview
http://www.youtube.com/watch?v=NdfD4Pod9ho
Conclusion
If there's no reason for a user to access relatively complex functionality
of a device, then there's no reason to expose it. It's just too easy for an
attacker to leverage official, inbuilt functionality and the web application
weaknesses.
In this case, overexposure of system services means we could write a rogue
application, compel a user to connect our app to the device using the
default credentials, and then use the already-inbuilt functionality to
perform unsolicited actions on the device. If we could get a user to
connect their device to their home Wi-Fi, we (or any website loaded within
the user's home network, in a JavaScript drive-by) could siphon all video
data, Wi-Fi passwords, and a list of local networks off it and send it
somewhere unsolicited.
Even without all that effort, if we can get anywhere near a Siime Eye and
crack into the Wi-Fi AP with a (most likely) weak or default password, we
can almost immediately get a root shell and a video stream.
If you're a user, change the Wi-Fi password to something complex and
long. And/or, try to get a response from Svakom—I didn't have much luck.
Disclosure timeline
24/12/2016—Svakom Informed about web interface issues. No response.
09/01/2017—Follow-up email sent to ask for some kind of response. No
response.
09/02/2017—Svakon informed of further code injection issues & intention
to write a blog post. No response.
Since there was no response at all after three attempts at contact, the
decision was made to publish.
PCMag.com http://www.pcmag.com/news/352820/14m-initiative-to-fight-fake-news-includes-facebook-mozill?utm_source=email&utm_campaign=whatsnewnow=utm_medium=title
NNSquad https://plus.google.com/+LaurenWeinstein/posts/HLdV23SLAaN I am convinced that the massive rise in Internet hate speech—including on YouTube in continuing conflict with Google's own terms of service—has been largely driven by ad network-based monetization systems. We made hate speech (and fake news) into profit centers. If we cut off the flow of income to these sickies on our platforms, we'll be doing humanity a great service. The hatemongers are of course still free to build their own distribution platforms and obtain funding from their own minions—away from decent people. The first amendment only applies to government actions against speech, not to private/corporate actions to stuff these vile animals back into their cages.
NNSquad https://www.buzzfeed.com/craigsilverman/fake-news-real-ads?utm_term=.mja7QVeKdG#.enaOGJNbMZ More than 60 websites publishing fake news are earning revenue from advertising networks and most of them are working with major networks such as Revcontent, Google AdSense, and Content.ad, according to a review by BuzzFeed News. An additional analysis, conducted in partnership with a co-investigator on of the forthcoming project A Field Guide to Fake News, found several cases where fake news sites that were kicked out of one network simply moved to another in order to continue earning money. It shows that in spite of calls for the digital ad industry to crack down on fake news and fraud in its ecosystem, fake news publishers continue to find ways to earn money from major advertising networks. The research also reveals that content-recommendation ad units, which provide ads made to look like real news headlines, were by far the most common ad format on the sites reviewed. But banner ads are still a factor: BuzzFeed News was served an ad for the Gap right next to a fabricated story about a sex offender pretending to be a woman in order to enter a washroom, and a false story about the pope.
The irony here is that in countries with oppressive regimes, Internet companies are praised for allowing people to communicate in secret to maintain some degree of freedom and strike a blow against totalitarianism, while in democratic Western countries Internet companies are lambasted for allowing people to communicate in secret and thus threaten our freedom and national security. As ever, there's no shortage of impractical ideas, such as proposals to make it a serious criminal offence to fail to decrypt an encrypted file or message when demanded by the authorities (yeah, right). While lots of people seem to think that governments can solve any problem by passing laws, there's the small matter that many of the companies and servers involved are outside the UK, so either we'd have to get other countries to agree to similar laws, or have a Chinese-style national firewall.
And of course, cryptology, with a weakened random number generator library: https://en.wikipedia.org/wiki/Random_number_generator_attack
Please report problems with the web pages to the maintainer