Tuesday, 29 July 2014

Apktool for Android security test in Windows

 
 


Use APKTool to Decompile, Edit, Translate and Recompile an APK
APKTool is an application  which decompiles and recompiles android APKs. If you know what you are doing, it also allows you to debug the smali code step by step. In our case it will enable us to build a language pack by translating the .xml strings inside APK files. 
This tutorial is for the Windows version of APKtool.
 The Google.Code page for APKTool is here, however, we have prepackaged everything you need and uploaded it here
The Video Tutorial is Below:
The Supplementary guide to common errors in APKTool is below:
You need to do the following preparations (the video outlines these steps anyway):
  1. Download the prepackaged APKTool zip.
  2. Extract them to a directory you will remember.
  3. Extract framework-res.apk AND apk files you want to decompile from the MIUI_Au ROM and copy them to the root directory of APKTool.
This step must be completed every time you are dealing with APKTool:
  1. Open a command window
  2. Navigate to the root directory of APKtool and type the following command:
    apktool if framework-res.apk
The output should be:
I: Framework installed to: C:\Users\Josh\apktool\framework\1.apk
This step does the actual decompiling of the APK (I will assume that the chosen APK is Settings.apk):
apktool d Settings.apk
The output should be:
I: Loading resource table…
I: Decoding resources…
I: Copying assets and libs…

After doing that, a new directory with the name of the APK you decompiled should have been created. You need to:
  1. Change into the newly created directory.
  2. Change into the /res folder
  3. Check to see if a values-xx folder exists, where xx is the two letter code of the target language to be translated into. For example, if you are aiming to translate into German, check for a values-de folder. If it does not exist (and chances are that if you are translating into a new language, that it will not exist), you need to create it. Then, copy the arrays.xml and strings.xml files from the /values folder into the folder you just created.
  4. Open these two files (in Notepad ++) and alter the strings (the text in BLACK ONLY).  Look out for things that look like  %d and %s /’  -    Don’t edit these, as they are variables.  Also, if you see &, it represents the ‘&’ sign, so feel free to change it. Finally, you MUST be sure to place a backslash ‘\’ before an apostrophe, for example Proxy\’s would be the equivalent of Proxy’s.
  5. Once you have translated and edited your arrays.xml and strings.xml files, save them, and return to the root directory of APKTool.
  6. Open a command prompt to that directory
Enter the following command to recompile your edited and translated APK (assuming that Settings.apk is the chosen APK):
apktool b Settings
The output should be:
I: Checking whether sources has changed…
I: Smaling…
I: Checking whether resources has changed…
I: Building resources…
I: Building apk file…

You may get a couple of these messages:
aapt: warning: string ‘app_killed_message’ has no default translation in C:\Users\Josh\Desktop\NF\framework-res\res; found: fr it ja
aapt: warning: string ‘global_action_reboot’ has no default translation in C:\Users\Josh\Desktop\NF\framework-res\res; found: fr it ja
aapt: warning: string ‘reboot_system’ has no default translation in C:\Users\Josh\Desktop\NF\framework-res\res; found: fr it ja
aapt: warning: string ‘toast_reboot_recommend’ has no default translation in C:\Users\Josh\Desktop\NF\framework-res

However,  it will build the apk anyway. These messages mean that some strings don’t have values. It is only an issues if the text im blue includes your translation language.
Once that is done, two directories will have been created within the decompilation directory. One will be called “dist”, and this is where it will place a built, but not signed, apk file. The other one is called “build”, and here it will place everything “loose” (the contents of the APK).
I have trouble using the APK files it spits out in the /dist folder ( they force closes if they are an application, or bootloop it a framework-res.apk; I think the reason is because Android will not accept APK files that are not signed).  Instead, copy the resources.arsc from the /build directory into the original framework-res from the rom (just overwrite the old resources.arsc one with the new one).
This tutorial is for the Windows version of APKtool.

Windows password hacking with Kalilinux

This tutorial describes the basics of using Kali linux tool  chntpw,

For those not familiar with it, chntpw is a Kali Linux tool that can be used to edit the windows registry, reset a users password, and promote a user to administrator, as well as several other useful options. Using chntpw is a great way to reset a Windows Password or otherwise gain access to a Windows machine when you don’t know what the password it.
Using chntpw is pretty straightforward, especially if you use interactive mode.

Mounting the Kali Linux live CD:
First, boot the Kali linux  CD, or other Linux Live CD.

1. Mount the windows partition. If you don’t know what device it is on, you can use the cfdisk command and it will tell you the device. The device should look something like “/dev/sda1.”
Mount the partition using the ntfs-3g or mount command:
ntfs-3g /dev/sda1 /mnt/windows
OR:
mount -t ntfs-3g /dev/sda1 /mnt/windows

Locate the Windows SAM File
2. Now, to make it a little easier, go ahead and switch to the location of the Windows Sam file and other hive files.
cd /mnt/WINDOWS/system32/config
*Note that in Windows Vista or Windows 7, the physical registry location is in "System32," with a capital "S"

To blank out or change the Windows password:

3. Type chntpw -h to familiarize yourself with the different options and usage of chntpw. If you like, you can actually use chntpw by giving it the appropriate option, but I like to use interactive mode, which makes it a little easier.
In addition to any options, you also have to give chntpw the location of the windows sam file, which stores the passwords, or the registry hives that you want to edit, which should all be in the config folder(Instead of WINDOWS, NT uses WINNT.)
4. Use the -i option to start chntpw in interactive mode and make sure to specify the name of the Windows sam file, as well as any other registry hive files you want to edit.
chntpw -i sam
Press “1” to edit the user password and then type the name of the user that you wish to edit and press enter.
You will now be given the option to blank out the password by pressing “1”, as well as several other ways to change the user, such as upgrading their account to an administrator.
Press “!” to exit the Edit User Screen and then press “q” to exit chntpw and you will be prompted to save any changes.


Successfully cracked windows password!!!!

Monday, 28 July 2014

Pentesting login pages

  

          Have you appeared for Penetration testing interview, or have you gone through the testing of banking or social networking site? If yes then hopefully you would be familiar with login page that is used to protect confidential information,critical system functionality or data with high integrity. Login page not only give you authority to change in to you account but also give freedom see the critical and confidential information behind the login page. Here is the set of test cases that would help you in getting the right job with a better understanding of a login page.

Steps are: 
  • Test with correct username and password: This is the most basic positive test cases, while using this user should successfully logged in.If correct username and password is not helping you to login in to your application then file a bug because this shows that something is wrong with application.
  • Verify that back button is not able to push you to your logged in page just after you logout from your specific account:  This kind of test cases invoke the flaw associated with Session management. When session is not closed just after your log-out means any one can access you account if you have opened your specific login enabled account at any time just by clicking Back button in Browser.So one way to save your account from such misconducts is to close browser when ever you log-out from your account.
  • Test with incorrect username or password: access should be denied
  • Test with correct username and empty password:  In this case when user click on login button then a message should flash that says “Enter a password or something unexpected went wrong”
  • Test with empty username and correct password: Again an error message should appear to enter a valid email or username
  • Verify the correct error messages like  Incorrect combination of user name and password. If you are getting anything like Incorrect username or Incorrect password then be conscious because you application is giving half the information to hacker and your application is in great danger.
  • Test a page url without login to application: For such thing login with correct username and correct password and go to certain page, copy the url and paste the same in another browser.if you are able to open the page then this application is not in good shape to protect the user’s information because anyone can open a specific page just by entering direct url.
  • Verify the session timeout: This is most important test case for any finance related site.Session should time out if user is inactive for few minute. This is normally a sustainability test of session. If your application is not prompting for session timeout then think once this may be issue.
  • Verify https in url for login page:  S with Http mean secure http. If login is associated with http in url means you information to login in to application is not secure and anyone can access your information just by doing small effort. While HTTPS ensure encryption of information that is being sent to server from client end.
  • Verify ID in url while processing your request :  keep track on ID associated with your request url and ID associated with request url should be dynamic not static otherwise this may help some hacker to nab your information.
  • Verify deletion of ID while browsing : Go to the place where cookies are saved and try to delete cookies when you are just browsing your account and try to find out the cookies that have your username and password because as soon as you delete that cookies you should be reached to login page. If you find the same cookies then try to change the numbers in cookies and should verify what is happening, hopefully corrupt cookies that have your real id should redirect you on login page once again even you haven’t deleted the cookies.
  • Try to login when your cookies are disable
  • Check SQL injection: most devastating vulnerabilities to  impact a business, as it can lead to exposure of all of the sensitive information stored in an application’s database, including handy information such as usernames, passwords, names, addresses, phone numbers, and credit card details.
    So I would suggest including this test cases if you are going to test some banking and insurance related application. Most common SQL injection that is used  or ‘1’=’1, if this got executed then be ready for the loss of your important information. If means hacker can login without any problem to system or application.
  • Verify account lock out: I would like to include this test case with priority, if user is using 3 or some specific number of time a wrong password then his/her account should be locked out and access should be allowed after certain assurance form filling or by calling customer care. This may help user from hackers hand.
  • Bruteforce attack: Lets have collection of Brute-force user-name and password file for attempt password attack
  • XSS check:  Execute reflected xss attack as username or password later both then check is application accepting the script to ensure the xss attack
  • Verify simultaneous login to application on different browser: I think you all would be familiar with this in daily life if you would have used railway ticket booking site.
  • Try some hit and trial username and password : before deploying application, username and password like Admin:Admin , Guest:Guest, some username :password, author:author  should be use to test but should be denied when application is deployed.
        These all test cases not only test the functionality but also test the security of the application. But I am not saying that these test cases are enough to test security of application. Because security testing is the part of testing that does not have any relation with requirement document so more and more effort is needed if we are talking about the security of an application.
Hope this would help you in testing login page
  • Test with incorrect username or password: access should be denied
  • Test with correct username and empty password:  In this case when user click on login button then a message should flash that says “Enter a password or something unexpected went wrong”
  • Test with empty username and correct password: Again an error message should appear to enter a valid email or username
  • Verify the correct error messages like  Incorrect combination of user name and password. If you are getting anything like Incorrect username or Incorrect password then be conscious because you application is giving half the information to hacker and your application is in great danger.
  • Verify that back button is not able to push you to your logged in page just after you logout from your specific account:  This kind of test cases invoke the flaw associated with Session management. When session is not closed just after your log-out means any one can access you account if you have opened your specific login enabled account at any time just by clicking Back button in Browser.So one way to save your account from such misconducts is to close browser when ever you log-out from your account.
  • Test a page url without login to application: For such thing login with correct username and correct password and go to certain page, copy the url and paste the same in another browser.if you are able to open the page then this application is not in good shape to protect the user’s information because anyone can open a specific page just by entering direct url.
  • Verify the session timeout: This is most important test case for any finance related site.Session should time out if user is inactive for few minute. This is normally a sustainability test of session. If your application is not prompting for session timeout then think once this may be issue.
  • Verify https in url for login page:  S with Http mean secure http. If login is associated with http in url means you information to login in to application is not secure and anyone can access your information just by doing small effort. While HTTPS ensure encryption of information that is being sent to server from client end.
  • Verify ID in url while processing your request :  keep track on ID associated with your request url and ID associated with request url should be dynamic not static otherwise this may help some hacker to nab your information.
  • Verify deletion of ID while browsing : Go to the place where cookies are saved and try to delete cookies when you are just browsing your account and try to find out the cookies that have your username and password because as soon as you delete that cookies you should be reached to login page. If you find the same cookies then try to change the numbers in cookies and should verify what is happening, hopefully corrupt cookies that have your real id should redirect you on login page once again even you haven’t deleted the cookies.
  • Try to login when your cookies are disable
  • Check SQL injection: most devastating vulnerabilities to  impact a business, as it can lead to exposure of all of the sensitive information stored in an application’s database, including handy information such as usernames, passwords, names, addresses, phone numbers, and credit card details.
    So I would suggest including this test cases if you are going to test some banking and insurance related application. Most common SQL injection that is used  or ‘1’=’1, if this got executed then be ready for the loss of your important information. If means hacker can login without any problem to system or application.
  • Verify account lock out: I would like to include this test case with priority, if user is using 3 or some specific number of time a wrong password then his/her account should be locked out and access should be allowed after certain assurance form filling or by calling customer care. This may help user from hackers hand.
  • Verify simultaneous login to application on different browser: I think you all would be familiar with this in daily life if you would have used railway ticket booking site.
  • Try some hit and trial username and password : before deploying application, username and password like Admin:Admin , Guest:Guest, some username :password, author:author  should be use to test but should be denied when application is deployed.
These all test cases not only test the functionality but also test the security of the application. But I am not saying that these test cases are enough to test security of application. Because security testing is the part of testing that does not have any relation with requirement document so more and more effort is needed if we are talking about the security of an application.
Hope this would help you in testing login page

Monday, 7 July 2014

NSA surveillance: A guide to staying secure

http://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2012/9/11/1347385573782/4ba3613c-8122-4311-8cc3-30d4a7f30473-460.jpeg

Now that we have enough details about how the NSA eavesdrops on the internet, including today's disclosures of the NSA's deliberate weakening of cryptographic systems, we can finally start to figure out how to protect ourselves.
For the past two weeks, I have been working with the Guardian on NSA stories, and have read hundreds of top-secret NSA documents provided by whistleblower Edward Snowden. I wasn't part of today's story – it was in process well before I showed up – but everything I read confirms what the Guardian is reporting.
At this point, I feel I can provide some advice for keeping secure against such an adversary.

The primary way the NSA eavesdrops on internet communications is in the network. That's where their capabilities best scale. They have invested in enormous programs to automatically collect and analyze network traffic. Anything that requires them to attack individual endpoint computers is significantly more costly and risky for them, and they will do those things carefully and sparingly.

Leveraging its secret agreements with telecommunications companies – all the US and UK ones, and many other "partners" around the world – the NSA gets access to the communications trunks that move internet traffic. In cases where it doesn't have that sort of friendly access, it does its best to surreptitiously monitor communications channels: tapping undersea cables, intercepting satellite communications, and so on.
That's an enormous amount of data, and the NSA has equivalently enormous capabilities to quickly sift through it all, looking for interesting traffic. "Interesting" can be defined in many ways: by the source, the destination, the content, the individuals involved, and so on. This data is funneled into the vast NSA system for future analysis.
The NSA collects much more metadata about internet traffic: who is talking to whom, when, how much, and by what mode of communication. Metadata is a lot easier to store and analyze than content. It can be extremely personal to the individual, and is enormously valuable intelligence.
The Systems Intelligence Directorate is in charge of data collection, and the resources it devotes to this is staggering. I read status report after status report about these programs, discussing capabilities, operational details, planned upgrades, and so on. Each individual problem – recovering electronic signals from fiber, keeping up with the terabyte streams as they go by, filtering out the interesting stuff – has its own group dedicated to solving it. Its reach is global.
The NSA also attacks network devices directly: routers, switches, firewalls, etc. Most of these devices have surveillance capabilities already built in; the trick is to surreptitiously turn them on. This is an especially fruitful avenue of attack; routers are updated less frequently, tend not to have security software installed on them, and are generally ignored as a vulnerability.
The NSA also devotes considerable resources to attacking endpoint computers. This kind of thing is done by its TAO – Tailored Access Operations – group. TAO has a menu of exploits it can serve up against your computer – whether you're running Windows, Mac OS, Linux, iOS, or something else – and a variety of tricks to get them on to your computer. Your anti-virus software won't detect them, and you'd have trouble finding them even if you knew where to look. These are hacker tools designed by hackers with an essentially unlimited budget. What I took away from reading the Snowden documents was that if the NSA wants in to your computer, it's in. Period.
The NSA deals with any encrypted data it encounters more by subverting the underlying cryptography than by leveraging any secret mathematical breakthroughs. First, there's a lot of bad cryptography out there. If it finds an internet connection protected by MS-CHAP, for example, that's easy to break and recover the key. It exploits poorly chosen user passwords, using the same dictionary attacks hackers use in the unclassified world.
As was revealed today, the NSA also works with security product vendors to ensure that commercial encryption products are broken in secret ways that only it knows about. We know this has happened historically: CryptoAG and Lotus Notes are the most public examples, and there is evidence of a back door in Windows. A few people have told me some recent stories about their experiences, and I plan to write about them soon. Basically, the NSA asks companies to subtly change their products in undetectable ways: making the random number generator less random, leaking the key somehow, adding a common exponent to a public-key exchange protocol, and so on. If the back door is discovered, it's explained away as a mistake. And as we now know, the NSA has enjoyed enormous success from this program.
TAO also hacks into computers to recover long-term keys. So if you're running a VPN that uses a complex shared secret to protect your data and the NSA decides it cares, it might try to steal that secret. This kind of thing is only done against high-value targets.
How do you communicate securely against such an adversary? Snowden said it in an online Q&A soon after he made his first document public: "Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on."
I believe this is true, despite today's revelations and tantalizing hints of "groundbreaking cryptanalytic capabilities" made by James Clapper, the director of national intelligence in another top-secret document. Those capabilities involve deliberately weakening the cryptography.
Snowden's follow-on sentence is equally important: "Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it."
Endpoint means the software you're using, the computer you're using it on, and the local network you're using it in. If the NSA can modify the encryption algorithm or drop a Trojan on your computer, all the cryptography in the world doesn't matter at all. If you want to remain secure against the NSA, you need to do your best to ensure that the encryption can operate unimpeded.
With all this in mind, I have five pieces of advice:
1) Hide in the network. Implement hidden services. Use Tor to anonymize yourself. Yes, the NSA targets Tor users, but it's work for them. The less obvious you are, the safer you are.
2) Encrypt your communications. Use TLS. Use IPsec. Again, while it's true that the NSA targets encrypted connections – and it may have explicit exploits against these protocols – you're much better protected than if you communicate in the clear.
3) Assume that while your computer can be compromised, it would take work and risk on the part of the NSA – so it probably isn't. If you have something really important, use an air gap. Since I started working with the Snowden documents, I bought a new computer that has never been connected to the internet. If I want to transfer a file, I encrypt the file on the secure computer and walk it over to my internet computer, using a USB stick. To decrypt something, I reverse the process. This might not be bulletproof, but it's pretty good.
4) Be suspicious of commercial encryption software, especially from large vendors. My guess is that most encryption products from large US companies have NSA-friendly back doors, and many foreign ones probably do as well. It's prudent to assume that foreign products also have foreign-installed backdoors. Closed-source software is easier for the NSA to backdoor than open-source software. Systems relying on master secrets are vulnerable to the NSA, through either legal or more clandestine means.
5) Try to use public-domain encryption that has to be compatible with other implementations. For example, it's harder for the NSA to backdoor TLS than BitLocker, because any vendor's TLS has to be compatible with every other vendor's TLS, while BitLocker only has to be compatible with itself, giving the NSA a lot more freedom to make changes. And because BitLocker is proprietary, it's far less likely those changes will be discovered. Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can.
Since I started working with Snowden's documents, I have been using GPG, Silent Circle, Tails, OTR, TrueCrypt, BleachBit, and a few other things I'm not going to write about. There's an undocumented encryption feature in my Password Safe program from the command line); I've been using that as well.
I understand that most of this is impossible for the typical internet user. Even I don't use all these tools for most everything I am working on. And I'm still primarily on Windows, unfortunately. Linux would be safer.
The NSA has turned the fabric of the internet into a vast surveillance platform, but they are not magical. They're limited by the same economic realities as the rest of us, and our best defense is to make surveillance of us as expensive as possible.
Trust the math. Encryption is your friend. Use it well, and do your best to ensure that nothing can compromise it. That's how you can remain secure even in the face of the NSA.

Tuesday, 29 April 2014

Skype leaves Sensitive User Data Unencrypted Locally On Computers




An application should always encrypt users' sensitive data, either it is local or stored on company servers, but still many popular services failed to provide fully secured solutions to their users.

Cristian Dinu (DrOptix) and DragoÅŸ Gaftoneanu, Romanian programmers at Hackyard Security Group, a private community dedicated to IT security research approaches 'The Hacker News' editorial and claimed that the Microsoft owned most popular free voice calling service Skype leaves its local database unencrypted, that puts users' sensitive information at risk.

All Skype-to-Skype voice, video, file transfers and instant messages are encrypted. Though, Skype's local database is also supposed to be encrypted because it is sensitive enough, but DragoÅŸ found that Skype leaves users’ full name, birthday, phone numbers, country, city and even full chat conversations unencrypted on the systems’ hard drive in a known location without any encryption or password.

Skype is a free online service that allows users to communicate with peers by voice using a microphone, video by using a webcam, and instant messaging over the Internet. Due to its worldwide popularity it was acquired by Microsoft Corporation on May 2011 for US$8.5 billion.

UNENCRYPTED SKYPE ACCOUNT LOCAL DATABASE

DragoÅŸ claimed that private information of skype users is stored in such a way that anyone with access to the device can see the private chats, usernames, phone number etc and use them for any purpose. 



Unencrypted data is obviously a loophole for cyber criminals and the Skype's unencrypted database also displays users’ location information such as country and city, which could be considered a jackpot for unsavory hackers.

While chatting with his friend 'Cristian Dinu' on Skype, DragoÅŸ noticed a folder in his Linux home directory that contains a database file, called main.db, created by the Skype software.

In Linux: /home/user/.Skype/skypename/
In Mac OS X: /Users/user/Library/Application Support/Skype/skypeuser
In Windows : C:\Users\Username\AppData\Roaming\Skype\skype.id

Using SQLite utility, DragoÅŸ connected to the unencrypted Skype database and found Skype user account related information in plaintext under different tables.

The Account table contains the basic information of the user such as skypename, fullname, birthday, country, city, mobile phone numbers, emails from Accounts, etc. 

Another Table labeled 'CallMembers' stores the information about when and whom user called. The 'Contacts' table stores the user’s friend list along with skypename, fullname, and some interesting columns, such as birthday, country, city and phone_mobile.

The most surprising table came out to be the 'Messages' Table that stores the users' chat conversations in complete plain text format. Even some tables regarding video calls and SMSes sent also reveals users’ personal data.

A flaw in the popular voice calling and messaging service may have left its Millions of users vulnerable to the attackers by storing the data in such a way that anyone can read it. The users’ details are kept inside one of Skype's database files buried within the file system, but anyone could see it if they had access to users' device and knew where to look.

It is quite easy to steal the history files and with the help of some special software one can view all the history without your Skype password.

The researcher tested this on the Linux based operating system but later it was found that the application makes the same files on every operating system.

Dragos advised users to remove the content of main.db every time they close Skype application and also provided a Linux based script to remove main.db automatically, which users just need to make it run on every startup. Users are advised to store their Skype profile files on the encrypted volume or in the encrypted container.

This is an example of poor software development practices. Microsoft should take proactive steps to ensure the privacy of users data.