On December 5, 2013 Twitter announced a new feature to tailor audience. Twitter tracks the website you visit in your browser using third party ad companies. The ad company would then process the collected data and send it back to Twitter. Twitter  uses this data to show the user tailored tweets. Luckily one can opt-out by making a change in Twitter settings.

The technique being used is called retargeting marketing, which means if a user visits a website without buying an item Twitter will follow you even after leaving the website and displays the ads repeatedly. Unfortunately this policy is enabled by default. To disable the so called “Promoted Content” one can do so by un-checking the option from Setting>Security and Privacy option

 In addition Twitter uses Tailored suggestion, which appears as suggested people to follow, based on the data sent from the ad companies.  To opt out, one can disable the Personalization option from the security and privacy setting.

Reference: http://nakedsecurity.sophos.com/2013/12/11/how-twitter-tracks-the-websites-you-visit-and-how-to-stop-it/

Not long ago, when received an email with images, Gmail would block the image by default. You had to press the “Display images below” button to see the images.

However, on Dec 12th, Google announced the that Gmail would once again load attached images by default. Together with the new policy, Google came out a new method to deal with the security issues: Google’s own proxy servers. In this way, all the images would be checked for viruses and malware before being showed.[1]

Although Google claimed it is a safe way, some experts commented it raise new security risks. It provides  senders ways to tell whether they emails were read by the receivers. If a sender is clever enough, for example, sending each mail with a unique image, he will easily know the behavior of each receiver. Besides, since image URLs in the e-mail are requested by Google’s servers, it may allow some malicious behavior to be automated by sending e-mail filled with images to Gmail accounts at random.[2]

To these concerns, Google replied that there is an option in settings to revert to the previous behavior for users who don’t like the change.[3]

This new changes is rolling out on desktop and to Gmail mobile apps in early 2014.

For more information, please check out the links below:

http://news.cnet.com/8301-1009_3-57615502-83/new-gmail-image-server-proxies-raise-security-risks/

http://www.wired.com/business/2013/12/gmail-spying-explained/

Reference:

[1] http://gmailblog.blogspot.com/2013/12/images-now-showing.html

[2] http://news.cnet.com/8301-1009_3-57615502-83/new-gmail-image-server-proxies-raise-security-risks/

[3] http://www.wired.com/business/2013/12/gmail-spying-explained/

Group: Jun Zheng (jz33) and Chao Zhang (cz15)

For the details please follow the link below:

http://xss.blogs.rice.edu/2013/12/02/comp527-weekly-report-dec-2-2013/

http://www.zdnet.com/cybersecurity-in-2014-a-roundup-of-predictions-7000023729/

There are a few interesting bits within this. First, it makes perfect sense that the finance industry consistently has the highest security ratings – when people have actual money on the line, they tend to care a lot more about things being secure.

Second, all of the projected events they listed come back to what Dan told us all semester long in 327, that security is a big game of cat and mouse between the good guys and the bad guys, highlighting the importance of staying one step ahead of them in everything we do.

As part of our continuing effort to keep our users’ information as secure as possible, we’re happy to announce that we recently enabled forward secrecy for traffic on twitter.com, api.twitter.com, and mobile.twitter.com. On top of the usual confidentiality and integrity properties of HTTPS, forward secrecy adds a new property. If an adversary is currently recording all Twitter users’ encrypted traffic, and they later crack or steal Twitter’s private keys, they should not be able to use those keys to decrypt the recorded traffic. As the Electronic Frontier Foundation points out, this type of protection is increasingly important on today’s Internet.

Under traditional HTTPS, the client chooses a random session key, encrypts it using the server’s public key, and sends it over the network. Someone in possession of the server’s private key and some recorded traffic can decrypt the session key and use that to decrypt the entire session. In order to support forward secrecy, we’ve enabled the EC Diffie-Hellman cipher suites. Under those cipher suites, the client and server manage to come up with a shared, random session key without ever sending the key across the network, even under encryption. The details of this remarkable and counterintuitive key exchange are explained at Wikipedia’s excellent article on Diffie-Hellman key exchange. The server’s private key is only used to sign the key exchange, preventing man-in-the-middle attacks.

There are two main categories of Diffie-Hellman key exchange. Traditional Diffie-Hellman (DHE) depends on the hardness of the Discrete Logarithm Problem and uses significantly more CPU than RSA, the most common key exchange used in SSL. Elliptic Curve Diffie-Hellman (ECDHE) is only a little more expensive than RSA for an equivalent security level. Vincent Bernat (@vince2_) benchmarked ECDHE at a 15% overhead relative to RSA over 2048-bit keys. DHE, by comparison, used 310% more CPU than RSA.

“Forward secrecy is just the latest way in which Twitter is trying to defend and protect the user’s voice.”

In practical deployment, we found that enabling and prioritizing ECDHE cipher suites actually caused negligible increase in CPU usage. HTTP keepalives and session resumption mean that most requests do not require a full handshake, so handshake operations do not dominate our CPU usage. We find 75% of Twitter’s client requests are sent over connections established using ECDHE. The remaining 25% consists mostly of older clients that don’t yet support the ECDHE cipher suites.

The last obstacle to correctly implementing forward secrecy was our use of TLS session tickets. We use TLS session tickets to allow clients to reconnect quickly using an abbreviated handshake if they still have a session ticket from a recent connection. Beside the CPU savings, this saves one network round-trip, commonly around 150ms and often much more on mobile networks.

Session tickets enable pools of servers to support session resumption without need for a shared session cache. However, as Adam Langley (@agl__) points out in his blog post How to Botch TLS Forward Secrecy:

If you run several servers then they all need to share the same session ticket key otherwise they can’t decrypt each other’s session tickets. In this case your forward secrecy is limited by the security of that file on disk. Since your private key is probably kept on the same disk, enabling forward secure cipher suites probably hasn’t actually achieved anything other than changing the file that the attacker needs to steal!

You need to generate session ticket keys randomly, distribute them to the servers without ever touching persistent storage and rotate them frequently.

We implemented such a key rotation system with a few additional goals: It should be simple to implement, simple to maintain, resistant to failure, and we should be able to restart the frontend process during deploys without waiting to receive new session ticket keys.

To do so, we have a set of key generator machines, of which one is the leader. The leader generates a fresh session ticket key every twelve hours and zeroes old keys after thirty-six hours. Keys are stored in tmpfs (a RAM-based filesystem), with no swap partitions configured. It’s important that there be no swap, because tmpfs will use swap if available, which could write keys to long-term disk storage.

Every five minutes, our frontends fetch the latest ticket keys from a key generator machine via SSH. This traffic is also forward secret by SSH’s Diffie-Hellman key exchange. Again, the keys are stored on a tmpfs, so they survive a restart of the frontend process without being leaked to disk.

When a new ticket key K is available, we don’t want to start encrypting new tickets with it until we expect that each frontend has a copy of K and can decrypt those tickets. We use a timestamp in K’s filename to determine its age; once it is at least twenty minutes old, it is considered current and frontends will start encrypting tickets with it.

In general, frontends will have three ticket keys available: the current key, and the two previous keys. They can decrypt session tickets using any of those three. When a client resumes a session using one of the previous keys, a frontend will finish the abbreviated handshake and assign a new session ticket using the current key. This logic is implemented in a callback provided to OpenSSL’s SSL_CTX_set_tlsext_ticket_key_cb.

The New Normal

At the end of the day, we are writing this not just to discuss an interesting piece of technology, but to present what we believe should be the new normal for web service owners. A year and a half ago, Twitter was first served completely over HTTPS. Since then, it has become clearer and clearer how important that step was to protecting our users’ privacy.

If you are a webmaster, we encourage you to implement HTTPS for your site and make it the default. If you already offer HTTPS, ensure your implementation is hardened with HTTP Strict Transport Security, secure cookies, certificate pinning, and Forward Secrecy. The security gains have never been more important to implement.

If you don’t run a website, demand that the sites you use implement HTTPS to help protect your privacy, and make sure you are using an up-to-date web browser so you are getting the latest security improvements.

Security is an ever-changing world. Our work on deploying forward secrecy is just the latest way in which Twitter is trying to defend and protect the user’s voice in that world.

Acknowledgements

Like all projects at Twitter, this has been a collaboration. We’d like to thank all involved, including: Jeff Hodges, Jeffrey Pinner, Kyle Randolph, Jan Schaumann, Matt Finifter, the entirety of our Security and Twitter Frontend teams, and the broader security and cryptography communities.

Links: https://blog.twitter.com/2013/forward-secrecy-at-twitter-0

Installed tweepy API.
It has all the 3 methods in single API:
1. Rest API
2. Streaming API and
3. Search API

Streaming API is useful to monitor live post with some keywords and/or hashtags. This will prove useful for government to report some tweets as soon as they get posted.

I put porn as a keyword and saw approx 2 posts per second being posted.

Also, I was looking through all the withheld tweets and did not find any single tweet that is missing from chillingEffects. So, I think, twitter is perfectly transparent.

I also found a nice article: http://thenextweb.com/twitter/2012/01/27/twitter-isnt-censoring-you-your-government-is/
which says, “Twitter isn’t censoring you. Your government is. ”

Is there a way to crawl through all the tweets till now and see “withheld_in_countries” parameter in that?

I have two updates:
1.
I wrote a third script using the REST API v1.1- tweet / GET statuses/show/id API
I ran the script by providing one of the withheld tweet ID: 357419942754267136 tweeted July 17th and requested withholding 10/1/13 on CE ( the same one I took snap shot last week see this doc)
I dumped the content to a text file and visually scanned the content here is some interesting fields [note the text field is the tweet content]
…
“id”:357419942754267136,
“id_str”:”357419942754267136″,
“text”:”http:\/\/t.co\/YsQlxs874J \u043a\u0443\u043f\u0438\u0442\u044c \u0433\u0430\u0448\u0438\u0448 \u043d\u0430 \u043c \u0442\u0435\u043a\u0441\u0442\u0438\u043b\u044c\u0449\u0438\u043a\u0430\u0445″
“screen_name”:”askajra”
“location”:””
…
“time_zone”:”Arizona”
“geo_enabled”:false,
“withheld_in_countries”:[“RU”]

I decoded the test field to char:
http:\/\/t.co\/YsQlxs874J купить гашиш на м текстильщиках

using google translate:
http: \ / \ / t.co \ / YsQlxs874J buy cannabis at m Tekstilshchiki
Comment: the user tweeted a link to drugs related stuff which was the reason for the withhold

Conclusion: we don’t have to be logged from the withholding country to find if the tweet was withheld. the “witheld_in_countries” will be returned

To do- write another API call to retrieve account info to see where the account was created (fyi: the name is russian)

Just to confirm my results, I ran the script against id: 389753553410981889 (one of my tweets I know they are not withheld) I looked for the withheld_in_countries field and sure enough it did not exist (output stored in text file (tweetbyid2Rtanash) on my machine

Conclusion: the witheld_in_countries field is sent only if the tweet is withheld in certain countries (this will be good to know when writing our robust crawler)

2.
Twitter transparency report
Cited from twitter:

• To minimize potential risk to our users, we’re not including specific numbers if fewer than 10 users / accounts are specified and we’ve not withheld any content in response to the particular request; instead you’ll see ‘< 10’ in the relevant cells.
• Where permitted by law, Twitter has published copies of the removal requests which have resulted in withheld content to Chilling Effects.
Which law are they referring to “when permitted by law”?
https://transparency.twitter.com/removal-requests/2012/jul-dec

Notice that the number they report here is much higher than what we found on chilling effects:18 (by June 30, 2013) when running the international query

We should have retrieved at least 102 international withhold requests which adds up to 135 withheld tweets total by July 2013

conclusion: not all international requests are reported on chilling effects. The Twitter transparency report is not specific and only includes graphs and some exmples see below

I changed my country setting to be Saudi Arabia, searched for several sex related hashtags in both English and Arabic. In all cases the pages viewed from Saudi were the same to the pages viewed from the US. This could mean one of several things.

1) Twitter is more sophisticated than we give them credit for in determining your location and the country setting is halfway a red herring
2) Twitters in depth process to requesting the withholding of each individual tweet is too much of a burden for the Saudi government to go through
3) The tweets are just being taken down instead of withheld

As it is, I’m willing to bet it’s more of 1) or 2), as there was still plenty of content for these hashtags.

A security researcher Oren Hafif has discovered a critical vulnerability in the password-reset system by Gmail. It allows attacker to get access of Gmail accounts of any user.

He demonstrated this attack leveraging Cross-site request forgery (CSRF), and cross-site scripting (XSS), and a flow bypass and tricking Google users into handing over their passwords via a simple spear-phishing attack.

Following are the steps in the attack

1. Select a target and compose an email which will look like email from Gmail Team.

2. Ask the user to confirm ownership of the account by clicking on a link.

3. Take the password from the user. [Most of the anti-phishing algorithms will fail here because the link redirects to https://www.google.com/… Same domain and keeps the user on the same domain through the attack.] {This is done using Cross-site request forgery (CSRF), }

4. Once the user enters the password, grab the password and cookies using XSS attack and tell the users that they have been hacked.

Following video includes the demonstration.

Mr. Hafif reported this issue to Google Security Engineers and they have fixed this bug now. They have also awarded Mr. Hafif $5100 under their Bug Bounty Program.

http://news.yahoo.com/exclusive-expert-warn-congress-healthcare-gov-security-bugs-144729835–sector.html

I think the following line about sums it up:

“They said HealthCare.gov runs on 500 million lines of code, or 25 times the size of Facebook, one of the world’s busiest sites.”

With spaghetti code like that, it’s no wonder that it’s hard to defend. The real wonder is that they still don’t want to take it down even knowing some of the vulnerabilities have been made public, and at the suggestion of 3/4’ths of the experts involved.

Group member: jz33 and cz15

Nov. 18, 2013

For supplement details of our group project, please visit the link below, thank you.

http://xss.blogs.rice.edu/2013/11/18/final-project-report-nov-18-2013/