Nilesh Kumar

It's a very trivial mistake a lot of developers do. They don't pay much attention to this simple looking misconfigurations which can be a big risk to apps. Generally they put much attention on other best practices such as intents, permissions etc, but tend to ignore the debuggable and allowbackup settings. I came across various such mistakes. The app is debuggable, which means we can attach a debugger to the process and step through every single instruction and even execute arbitrary code in the context of app process. Similarly, allowbackup is used to determine if to allow the application to participate in the backup and restore infrastructure. This leads to potential data leakage. If not required, harden the configuration file by setting the values= “False” Reference: developer.android.com/guide/topics/manifest/application-element.html

This is a tricky situation as you can't see the page source to look for the tags such as embed etc. All you see is the entire page loads as Flash content and plugins like InspectElement will not work. I came across the similar scenario. So, this is how we can sort out this issue. Every browser has flash plugins to display flash contents in the browser itself. So, if we disable the plugin the browser won't be able to display it within and will attempt to download it on harddisk, which can be used for security analysis. Here how to do in case of Chrome. Just disable the plugin from the browser:

Where Wireshark fails, this great tool comes into rescue. Just came across it, wanted to share. It can sniff any interface that has got an IP address, including 127.0.0.1 (localhost/loopback): http://www.netresec.com/?page=Blog&month=2011-04&post=RawCap-sniffer-for-Windows-released

I came across a strange behavior in one web application. In one tab logged into the web application and in another tab I accessed the login page again. I was thrown out of the first logged in tab too. Is it desired behavior? I guess the session IDs are shared across tabs and and once logged in one tab can access any page in other tabs. Let me know if you have any answer.

Sometimes we come across with the login pages which are not initially served over https, rather it's redirected to https.  The second scenario is wherein, the login page is served over http but the login section in that page is loaded in a  frame, where the credentials are submitted over https. Both can be considered as an insecure design as both are susceptible to MITM attacks. Because the login form was loaded over HTTP, it was open to modification by a malicious party. Every link/URL present on that page (not just the form action) needs to be served over HTTPS. This will prevent Man-in-the- Middle attacks on the login form. An attacker who exploited this design vulnerability would be able to utilize the information to escalate their method of attack, possibly leading to impersonation of a legitimate user, the theft of proprietary data, or execution of actions. The best defense comes from user's perspective, where a user may directly access the website ove

Risks of Using Self Signed Certificate for Authenticity: Anyone can create a self-signed certificate, and anyone can put whatever meta-data that they want into it. So, two self-signed certificates can look and behave identically, one can't visually distinguish between a legitimate and a forged certificate. It means, anyone can create similar cab file & digitally sign using self-signed legitimate or forged certificates, send to our customers. The customer will not able to differentiate between fake and genuine one. Risks of Using Self Signed Certificate for Integrity: User creates a file for distribution using his own self signed certificate and sends to receiver. Here an attacker too creates a his own self-signed certificate with the same name. Attacker does a MITM, captures User’s data, modifies it, removes the signature (in case of dlls, exes just remove from PE header), re-signs with his own self-signed certificate and forwards it to the receiver. This way the data can be

Stumbled upon a good post about a new kind of authentication mechanism, presented by Bionic Labs in Recode conference: See yourself: http://recode.net/2014/05/29/a-new-kind-of-security-bionic-labs-wants-to-call-your-friends-to-verify-youre-you/

This article explains the Heartbleed bug and shows how it can be exploited.   http://resources.infosecinstitute.com/exploiting-heartbleed/

Was about to write about this, meanwhile found this post very useful. Why to reinvent the wheel? So here you go: http://www.garage4hackers.com/blog.php?b=2551 Written by Rahul Sasi.

I came across one application while doing security assessment and found that they were using default admin account.And that too the admin account was having credentials as admin:admin. Catastrophic, isn't it? I raised this issue before completing the assessment with the developers. They had their usual excuse- this was introduced to help user reset their passwords through the web application and since the web application was supposed to be used by singles user. It was essentially a single user environment. The web application was running locally on their individual laptops and the laptop was being plugged on the LAN just for few moments to reset some device readings. Now the risk was: Even a momentarily the laptop was connected to local network, the default admin account's presence was known to every other user. If they change the password using the default account then? Though this was single user environment and only very few users were supposed to use the application o

Controllers are an essential part of ICS (Industrial Control Systems) network. Generally they are interface to many field devices such as sensors and placed within closed network. Exposing them outside world may be disastrous and they can be configured/ mis- configured to carry put attacks which can have dangerous impact on human being's life and safety. So, it's necessary to do a security assessment of ICS networks to uncover potential vulnerabilties. In brief, to test a controller we need to: Understand the entire architecture- the platform, technologies, protocol it understands. Do a quick threat modeling here. Review Network architecture, see how the controller is placed, ideally it should not be reachable from internet. Firmware testing: Most of the controllers have embedded systems on them. Do a firmware testing here- De compiling, modifying, patching, looking for hard coded sensitive credentials. How the firmware is uploaded/ downloaded- how secure is the mechan

Encryption: It prevents reverse engineering of the firmware. The firmware might be stored in encrypted form and only decrypted when it is to be executed, or it might be decrypted during the firmware update process. • Signing: is concerned with ensuring that a message has not been corrupted or modified while in transit. This is important since a malicious user cannot be allowed to alter the firmware originally delivered by the firmware producer. • No hardcoded credentials: The presence of hard-coded accounts that can serve as backdoors to devices. • Code obfuscation: it makes runtime analysis difficult. • Authentication: Make it difficult for unauthorized users to obtain the firmware updates. Make it restrictive, less exposed. • If the device is capable of being networked, no unnecessary services are running and ensure that it can also alert and log when firmware has been updated.