Archive for the Application Category

Skype? Microsoft reads everything you write!

Posted in Application, Encryption, Network Security, Valnurability with tags , , on May 23, 2013 by keizer

Thanks goes to The-H, for their original post @ h-online.com

Anyone who uses Skype has consented to the company reading everything they write. The H’s associates in Germany at heise Security have now discovered that the Microsoft subsidiary does in fact make use of this privilege in practice. Shortly after sending HTTPS URLs over the instant messaging service, those URLs receive an unannounced visit from Microsoft HQ in Redmond.

A reader informed heise Security that he had observed some unusual network traffic following a Skype instant messaging conversation. The server indicated a potential replay attack. It turned out that an IP address which traced back to Microsoft had accessed the HTTPS URLs previously transmitted over Skype. Heise Security then reproduced the events by sending two test HTTPS URLs, one containing login information and one pointing to a private cloud-based file-sharing service. A few hours after their Skype messages, they observed the following in the server log:

65.52.100.214 - - [30/Apr/2013:19:28:32 +0200]
"HEAD /.../login.html?user=tbtest&password=geheim HTTP/1.1"

the source...
The access is coming from systems which clearly belong to Microsoft.      source: utrace

Source: Utrace They too had received visits to each of the HTTPS URLs transmitted over Skype from an IP address registered to Microsoft in Redmond. URLs pointing to encrypted web pages frequently contain unique session data or other confidential information. HTTP URLs, by contrast, were not accessed. In visiting these pages, Microsoft made use of both the login information and the specially created URL for a private cloud-based file-sharing service.

In response to an enquiry from heise Security, Skype referred them to a passage from its data protection policy:

“Skype may use automated scanning within Instant Messages and SMS to (a) identify suspected spam and/or (b) identify URLs that have been previously flagged as spam, fraud, or phishing links.”

A spokesman for the company confirmed that it scans messages to filter out spam and phishing websites. This explanation does not appear to fit the facts, however. Spam and phishing sites are not usually found on HTTPS pages. By contrast, Skype leaves the more commonly affected HTTP URLs, containing no information on ownership, untouched. Skype also sends head requests which merely fetches administrative information relating to the server. To check a site for spam or phishing, Skype would need to examine its content.

Back in January, civil rights groups sent an open letter to Microsoft questioning the security of Skype communication since the takeover. The groups behind the letter, which included the Electronic Frontier Foundation and Reporters without Borders expressed concern that the restructuring resulting from the takeover meant that Skype would have to comply with US laws on eavesdropping and would therefore have to permit government agencies and secret services to access Skype communications.

In summary, The H and heise Security believe that, having consented to Microsoft using all data transmitted over the service pretty much however it likes, all Skype users should assume that this will actually happen and that the company is not going to reveal what exactly it gets up to with this data.

Pool Party!

Posted in Application, Mobile with tags , , , on January 29, 2013 by keizer

Pool Party

A new social pool game by nitako – pool party was recently released to the mobiles (iphone and android)- letting you play pool against Facebook users, using turns.

It is actually a pretty cool game, I played it (normally) for about 2 weeks… getting better and better. I must say, once you get how it works, its pretty easy to score the balls. As you earn more and more coins, you want play on larger pots. And that’s what I did… Now, you probably know the saying “Don’t put all your eggs in one basket”, so I did :\ – playing with all my coins against one dude, which turned out to be better then then I expected, which led me to lose all my coins!

This is when I lost my temper… after all the time & effort I put in this game, I left with nothing! It’s time to use my profession skills for something truly important! let’s try and get more coins… and fast!

So I started digging in the application’s traffic… changing the amount of coins, pots, cash… every variable that held an amount of coins, I changed it… but nothing!

Until I found a way… which,  to my disappointment, includes taking others’ coins 😦 oh well… its not real money 🙂

and this is how it works:

Play a game, until you win (it doesn’t matter on what amount you’re playing on)  and the game ends – catch the requests. One of them will look like this (notice the tableData=) :

org_req

Copy the part from the tableData= to the end of the request – which should say: result=EightSank – and paste it into a notepad or any other text editor.  Next time you’re playing with someone, just after hitting the ball – intercept the requests (using any proxy application), and when you see the requests that holds the tableData – replace it with the text you saved, which represents the insertion of the 8 ball, which indicates that you have won. 

Now, let’s see it in action:

1. I have 12,250 coins:

before

2. Oh, it’s my turn,  so I’ll just turn the requests interception ON :

ur_turn

3. After hitting the ball (it doesn’t matter what actually happens in the game), I find the request we discussed earlier and replaced the tableData part. Which in this case saying result=TurnOver (guess not…:))

tamper24. With the EightSank tableData – I saved from one of my (many) victories:

tamper3

5. Its magic! most of the balls are still on the table, but it says clearlyYou Cleared the table ! the game ends with a pot of $200 :

cleared

6. Voilà! I now have 12,350 coins (Of course, I invested 100 myself, so the actual profit is, in this case, 100$)…

after

If you liked that post, and you want me to find you fast& easy ways to earn coins – comment with the name of the iphone game you want, and I’ll do my best.

Cheers!

Hack into Skype in 6 simple steps:

Posted in Application, Valnurability with tags on November 26, 2012 by keizer
Major vulnerability of Skype’s password reset system has went public today.
The only thing you need to obtain full access to any Skype account is primary email of that account (the email which used when the Skype account been registered).
Following guide contains both – how to steal an account, and how to protect your account (scroll down for that).

Update 1 (November 14, 2:00am PDT): Skype made the password reset system disabled. So link on the step 4 is not working for me now (starting from November 14, 2 am PDT).
Update 2 (November 14, 6:00am PDT): Skype re-enabled the password reset system, but now it will not sent recovery token to attacker’s client. The hole (gate, almost highway road) is closed.

For example, I know somebody’s email – crackme33@yahoo.com , let’s hack his Skype!

1. Go to the Skype website, register new disposable account. In email field, put target’s email.

If the email, you typed into form, attached to some skype account, then it will say that “You already have a Skype account”, that means you can hack it!
So, complete the form, provide some fake BOD, gender, country, answer to question “How do you intend to use Skype?” as personal, fill any skype name (REMEMBER IT), it will give you some suggestions of not taken ones, assign some password  (REMEMBER IT), solve the captcha, proceed forward – push the continue button.
You will be redirected to you new account dashboard. Logout from it.

 

2. Run the Skype application with those new credentials.
3. Since we just logged in to a fresh account, at home screen of the Skype application, there will be advertisement “Find your friends and say hello”, click somewhere to bring focus on that part of screen (I clicked where the red cross is drawn):
Then push F5 button on your keyboard, it will refresh the home screen. Do that 3-4 times until you see “Bring your Facebook friends into Skype” advertisement. Click “No thanks, blah-blah-blah”.
You will get the home screen with some banner.
4. Go to Skype’s password reset system.Put the target’s email. In my case – crackme33@yahoo.com .
Click “Submit button”, and after several seconds, you will see Skype’s pop-up notification – “Password token”.
5. Go to Skype application, on the home screen you will see Password token, click on “more info”, go to “temporary code link”:
6. Browser will open page, where you can select any skype account registered to target email, in my case there are two account – my disposable and target:
Choose target’s account and click “Change password and sign me in”:

You will be redirected to login form:

You are all set!
P.S. I have changed primary email for that test accounts, so do not try hack them. Just in case. =)

How to protect your accounts

You already changed password for the target account, know the skype login, and able to use that target skype account. But somebody could take it back from you, just as you did (owner for example).
To prevent that you need to change your primary email to some address, unknown to anyone.

To do that:
1. Sign in on skype website.
2. Go into the “profile” link (click to enlarge):

3. On account information, go down, to “Contact details”, click “Add email address”:
4. Add your email address, which unknown to anybody, but you:
Click save button at the bottom of the form. After page reload, refresh page again to prevent some strange glitches of the site (if you will not reload the page, after you do following steps, it will forget steps 4 and 5 and discard that little work).
5. Scroll to Contact details again. Click on “Add email address” again. Switch primary email to the new one:
Click “Save” button at the bottom of the form, again.
It will ask you for your password. You know it already. Type password and click button by mouse, not by “Enter” key.
After page reload, refresh page again to prevent some strange glitches of the site (described above).
6. Scroll to Contact details again. Click on “Add email address” again. Delete (with backspace and/or delete buttons) all emails but primary:
7. Click “Save” button at the bottom of the form. Make sure all your changes applied (it sometimes require two or more attempts, since the site is developed by curly-handed programmers).
8. Tell to friends how to protect a skype account. ASAP

At the time there is no other way to protect your skype account, except changing of primary email to some unknown address.
Once account is stolen, it has ability to retrieve all your IM history from other peers.
If you already lost your account, contact to all your necessary contacts and tell them to remove you from their contact list. It prevents IM history interchange (if it is not already happened).

There is how mailbox of target looks like:

Thus target will receive notifications regarding password change, but initial owner have less than one minute to understand and take action, it is almost impossible to login into skype website, change emails, when a hacker already there.

Disclaimer: The information provided on in this blog is to be used for educational purposes only. The blog author is in no way responsible for any misuse of the information provided.
Posted 2 week ago by Ivan Koldaev

Path Traverser – a new Path Traversal tool

Posted in Application, Programming, Valnurability with tags , , , on June 17, 2012 by keizer

New development by me 🙂

Path Traverser is a tool for security testing of web applications. It operates as a middleman between your web application to its host server, giving you the abillity to test the actual files as found in your host server against the application, according to their relevant path.

How does it work?

After you have provided the relevant details, Path Traverser will connect (FTP) to your host server in order to pull out (ls -R) the list of files.

Then, it will manipulate the list taken from the file system so it will fit the web application by changing their path. How? Lets say that your application could be found at: http://mysrvr:777/home and the application files could be found in the file system under: myapps/demoapp/client/version/lastversion. Each file in the files system will receive its relevant path, so the files under: /myapps/demoapp/client/version/1.1/ will be created as: http://mysrvr:777/home/../1.1/ and requests for files under /myapp/differentapp/files/ will be created as: http://mysrvr:777/home/../../../../differentapp/files/, etc.

After that, the Path Traverser will start sending these requests one by one. You will be able to follow via the progress bar or the log file. If something goes worng, go to the Log Tab and try to figure up what when wrong, or contact me at: pt@appsec.it – I will gladly help!
Now its time to view the results, that could be found in the Results Tab. Each request that received one of the selected response codes from the server, will be displayed next to the code in the Results Tab. e.g.: [200]   http://http://mysrvr:777/home/../1.1/actions.log. They could also be found under in the file holding the relevant response code.

Where? appsec.it/pt – for more information!

for help: appsec.it/pt/help.html


Here are some screenshots:





Of course, all features and assistant could be found in the Path Traverser website:

http://appsec.it/pt

LinkedOut! LinkedIn is violating your privacy

Posted in Application, Network Security on June 7, 2012 by keizer

LinkedIn’s mobile application has an interesting feature that allows users to view their iOS calendars within the app. However, it turns out that LinkedIn have decided to send detailed calendar entries of users to their servers. The app doesn’t only send the participant lists of meetings; it also sends out the subject, location, time of meeting and more importantly personal meeting notes, which tend to contain highly sensitive information such as conference call details and passcodes. If you have decided to opt-in to this calendar feature in iPhone, LinkedIn will automatically receive your calendar entries and will continue doing so every-time you open your LinkedIn app.

What is the problem exactly?
LinkedIn’s app collects full meeting details from one’s iOS calendar, which contains sensitive information such as meeting notes. While accessing this information locally by the app is not a problem by itself, this information is collected and transmitted to LinkedIn’s servers; moreover, this action is currently performed without a clear indication from the app to the user, thus possibly violating Apple’s privacy guidelines (section 17.1: “Apps cannot transmit data about a user without obtaining the user’s prior permission and providing the user with access to information about how and where the data will be used”). The biggest problematic factor lies in the fact that most of the transmitted information is not required for the app’s functionality, as described later on.

What information is being collected and sent to LinkedIn’s servers?
Every time you launch LinkedIn’s app for iPhone, it automatically sends out all of your calendar entries for a five-days time frame. The meetings information is being collected from all the calendars on the iOS machine, thus possibly exposing information from both personal and corporate calendar accounts.
Calendar meeting that are being sent out contain: meeting title, organizer and attendees, location, time and meeting notes. It should be noted that the names and email addresses of the meeting organizer and attendees are collected even for those who do not have a LinkedIn account.

As an example, creating a financial results meeting in your private calendar leads to data leakage to LinkedIn during your normal usage of the LinkedIn app. Below you can find the actual leaked data, which was acquired by analyzing the traffic the app generates.

Calendar details traffic leakage

Is the collected information needed for LinkedIn’s functionality?
Not that we are aware of. In order to implement their acclaimed feature of synchronizing between the people you meet and their LinkedIn profile, all LinkedIn need is unique identifiers of the people you are going to meet with, not all the details of your planned meetings; details such as meeting schedule, location, title or notes, which tend to be sensitive in particular for organizations, are irrelevant for this task.

What should LinkedIn do?
In order to achieve its desired functionality, the LinkedIn app should refrain from sending full meeting details to their servers. Instead, the app should communicate to LinkedIn’s servers only a small relevant subset such as the attendees of the meeting. In a matter of fact, the users’ privacy can be further improved by sending-over hashed versions of the contacts data instead of the raw contacts data, thus preserving a better privacy model.
In addition, we believe the app should clearly communicate to its users the kind of information it sends back to LinkedIn’s servers.
We have communicated the aforementioned to LinkedIn, and understand it is being examined by their Risk and Privacy Operations team. However, at the time of writing this post, the issue is still not fixed.

What should Apple do?
On a more strategic level, there may be additional mobile applications that extract sensitive calendar details and then transmit them out of the device. At the moment, such applications may be able to do so without a clear indication to the user, thus possibly violating Apple’s privacy guidelines. Therefore, we believe Apple could improve their screening process by leveraging static analysis technologies to detect such violations and better enforce its privacy policy on submitted applications.

Have LinkedIn used the acquired information in a bad way? Did LinkedIn have bad intentions?
To the best of our knowledge and based on LinkedIn’s good reputation and leadership in the market, we do not believe it utilized the collected information in a malicious way. However, we are concerned by the fact it collects and sends-out sensitive information about its users, without a clear indication and consent.

How can I verify I’m not affected by this privacy leak?


The following instructions cover the actions that need to be done to verify your calendar(s) information is not being transmitted to LinkedIn’s servers. These instructions apply for the most updated iPhone LinkedIn version. Similar actions can be applied for the iPad version of the app.
1. Click on the LinkedIn icon in the upper left part of the screen
2. Click on the “You” view
3. Click on the settings icon in the upper right part of the screen
4. Click on the “Add Calendar” option in the Settings page
5. Toggle off the “Add Your Calendar” option.

Discovered by:
Adi Sharabani and Yair Amit, Skycure

SALT

Posted in Application, Encryption, JAVA on January 26, 2012 by keizer

salt

Hashing – Using SALT properly

Technically, the salt should be unique. The point of the salt is to be individual for each hashed password. The best way to do it is using a random selection with an unpredictable random generator, preferably within a salt space large enough to make collisions improbable (two instances using the same salt value).

Well, sometime it is tempting to try to create a salt from some data which is “presumably unique”, such as the user ID, but it is WRONG! here is why:

1. If you use for example the user ID, an attacker can just pre create a tables for user IDs 1 to 9999 – since a user ID is unique only per system but not worldwide.

2. The same applies to the username: there is one “root” per Unix system, but there are many roots in the world – a rainbow table for “root” could be applied to millions of systems and thus probably have been generated already. Worse yet, there are also many “bob”s and “john”s, and their passwords could be quite weak.

3. Sometimes, users change their password. For each new password, a new salt must be selected – otherwise, an attacker obtained the hash of the old password and the hash of the new could try to attack both simultaneously.

Here is an example for how to use salt:

import java.security.MessageDigest;

public byte[] getHash(String password, byte[] salt) {
MessageDigest digest = MessageDigest.getInstance(“SHA-256”);
digest.reset();
digest.update(salt);
return digest.digest(password.getBytes(“UTF-8”));
}

To slow down the computation it is recommended to iterate the hash operation n times. While hashing the password n times does slow down hashing for both attackers and typical users, typical users don’t really notice it being that hashing is such a small percentage of their total time interacting with the system. On the other hand, an attacker trying to crack passwords spends nearly 100% of their time hashing so hashing n times gives the appearance of slowing the attacker down by a factor of n while not noticeably affecting the typical user.
The stored password looks like this : Hash(hash(hash(hash(……….hash(password||salt)))))))))))))))

and the implementations should be as follows:


import java.security.*;

public byte[] getHash(int iterationNb, String password, byte[] salt) {
MessageDigest digest = MessageDigest.getInstance(“SHA-1”);
digest.reset();
digest.update(salt);
byte[] input = digest.digest(password.getBytes(“UTF-8”));
for (int i = 0; i < iterationNb; i++) {
digest.reset();
input = digest.digest(input);
}
return input;
}

Thanks also to: OWASP

The BEAST – SSL Crack

Posted in Application, Encryption, Malware, Network Security, Valnurability on October 24, 2011 by keizer

Researchers have discovered a serious weakness in virtually all websites protected by the secure sockets layer protocol that allows attackers to silently decrypt data that’s passing between a webserver and an end-user browser.

The vulnerability resides in versions 1.0 and earlier of TLS, or transport layer security, the successor to the secure sockets layer technology that serves as the internet’s foundation of trust. Although versions 1.1 and 1.2 of TLS aren’t susceptible, they remain almost entirely unsupported in browsers and websites alike, making encrypted transactions on PayPal, GMail, and just about every other website vulnerable to eavesdropping by hackers who are able to control the connection between the end user and the website he’s visiting.

At the Ekoparty security conference in Buenos Aires later this week, researchers Thai Duong and Juliano Rizzo plan to demonstrate proof-of-concept code called BEAST, which is short for Browser Exploit Against SSL/TLS. The stealthy piece of JavaScript works with a network sniffer to decrypt encrypted cookies a targeted website uses to grant access to restricted user accounts. The exploit works even against sites that use HSTS, or HTTP Strict Transport Security, which prevents certain pages from loading unless they’re protected by SSL.

The demo will decrypt an authentication cookie used to access a PayPal account, Duong said. Two days after this article was first published, Google released a developer version of its Chrome browser designed to thwart the attack. Update here.
Like a cryptographic Trojan horse

The attack is the latest to expose serious fractures in the system that virtually all online entities use to protect data from being intercepted over insecure networks and to prove their website is authentic rather than an easily counterfeited impostor. Over the past few years, Moxie Marlinspike and other researchers have documented ways of obtaining digital certificates that trick the system into validating sites that can’t be trusted.

Earlier this month, attackers obtained digital credentials for Google.com and at least a dozen other sites after breaching the security of disgraced certificate authority DigiNotar. The forgeries were then used to spy on people in Iran accessing protected GMail servers.

By contrast, Duong and Rizzo say they’ve figured out a way to defeat SSL by breaking the underlying encryption it uses to prevent sensitive data from being read by people eavesdropping on an address protected by the HTTPs prefix.

“BEAST is different than most published attacks against HTTPS,” Duong wrote in an email. “While other attacks focus on the authenticity property of SSL, BEAST attacks the confidentiality of the protocol. As far as we know, BEAST implements the first attack that actually decrypts HTTPS requests.”

Duong and Rizzo are the same researchers who last year released a point-and-click tool that exposes encrypted data and executes arbitrary code on websites that use a widely used development framework. The underlying “cryptographic padding oracle” exploited in that attack isn’t an issue in their current research.

Instead, BEAST carries out what’s known as a plaintext-recovery attack that exploits a vulnerability in TLS that has long been regarded as mainly a theoretical weakness. During the encryption process, the protocol scrambles block after block of data using the previous encrypted block. It has long been theorized that attackers can manipulate the process to make educated guesses about the contents of the plaintext blocks.

If the attacker’s guess is correct, the block cipher will receive the same input for a new block as for an old block, producing an identical ciphertext.

At the moment, BEAST requires about two seconds to decrypt each byte of an encrypted cookie. That means authentication cookies of 1,000 to 2,000 characters long will still take a minimum of a half hour for their PayPal attack to work. Nonetheless, the technique poses a threat to millions of websites that use earlier versions of TLS, particularly in light of Duong and Rizzo’s claim that this time can be drastically shortened.

In an email sent shortly after this article was published, Rizzo said refinements made over the past few days have reduced the time required to under 10 minutes.

“BEAST is like a cryptographic Trojan horse – an attacker slips a bit of JavaScript into your browser, and the JavaScript collaborates with a network sniffer to undermine your HTTPS connection,” Trevor Perrin, an independent security researcher, wrote in an email. “If the attack works as quickly and widely as they claim it’s a legitimate threat.”

from theregister.co.uk