Wednesday, September 28, 2011
Wednesday, July 27, 2011
7 UID bogus centers shut down
In what comes as an addition to fraud incidents in the city, seven Unique Identification Centers were shut down by the civic corporation on Monday. The Thane Municipal Corporation (TMC) closed down these seven bogus UID centers where several citizens have already got their UID forms enrolled.
However, the process will be declared as void as these centers are not legal. The seven mentioned centers were operating without any permission from the authorities since the past few months. Two centers in Panchpakhadi, Lokmanya Nagar and Khopat each and one center in Vrindavan society were shut down by the municipal corporation. The TMC has made it clear that citizens who enrolled themselves in these centers will not get their UID cards and will have to enroll themselves all over again at an authorised centre in the city.
Informed sources from TMC maintained that Vakhrangee Software Ltd. was using a bank's name to provide UID cards to citizens and some Maharashtra Navnirman Sena activists were believed to be running the bogus centers. It is learnt that a corporator informed the civic body about the bogus centers following which the TMC took a stern action and Additional Commissioner of TMC, L R Gupta, summoned Rahul Devpal, the owner of the software agency. During interrogation, it was revealed that these centers were bogus.
Many citizens have already enrolled themselves for the scheme but will again have to redo the process. A woman requesting anonymity said, "My son went to the center at Vrindavan Society and waited there for around four hours to get himself enrolled. All those efforts have proved futile. The civic body had opened 40 such centers in the city this year and each center enrolls 50 person's UID forms each day. The government had allotted the work to authorised banks, government undertaking organisations and others. The central government started the UID scheme which is also known as Aadhar to provide citizens a 12-digit identification number under the Unique Identification Authority of India.
However, the process will be declared as void as these centers are not legal. The seven mentioned centers were operating without any permission from the authorities since the past few months. Two centers in Panchpakhadi, Lokmanya Nagar and Khopat each and one center in Vrindavan society were shut down by the municipal corporation. The TMC has made it clear that citizens who enrolled themselves in these centers will not get their UID cards and will have to enroll themselves all over again at an authorised centre in the city.
Informed sources from TMC maintained that Vakhrangee Software Ltd. was using a bank's name to provide UID cards to citizens and some Maharashtra Navnirman Sena activists were believed to be running the bogus centers. It is learnt that a corporator informed the civic body about the bogus centers following which the TMC took a stern action and Additional Commissioner of TMC, L R Gupta, summoned Rahul Devpal, the owner of the software agency. During interrogation, it was revealed that these centers were bogus.
Many citizens have already enrolled themselves for the scheme but will again have to redo the process. A woman requesting anonymity said, "My son went to the center at Vrindavan Society and waited there for around four hours to get himself enrolled. All those efforts have proved futile. The civic body had opened 40 such centers in the city this year and each center enrolls 50 person's UID forms each day. The government had allotted the work to authorised banks, government undertaking organisations and others. The central government started the UID scheme which is also known as Aadhar to provide citizens a 12-digit identification number under the Unique Identification Authority of India.
Tuesday, July 26, 2011
Mobile Apps Security – Are you worried?
Smart Mobile devices are now increasingly been adopted by the consumers and in the enterprise leading to a number of organizations interested in custom development of mobile applications. Software vendors developing mobile applications are on most occasions feeling enormous pressure to meet extremely tight Go to Market timelines. This often leaves security neglected or compromised.
The trends already mention mobile apps taking a plight in the financial sector, with online banking, online trading apps. Security, although a prime driver for custom development, is one of the hardest aspects to get right. The industry is starting to see the security & privacy concerns in developing mobile applications. Initiatives and best practices are been released by groups like OWASP that have been addressing mobile security in a big way. There is a need to leverage the native security APIs of the platform, handle sensitive data with care, and choose the right data protection classes for the mobile application architecture. Let us make an attempt to look at few critical weaknesses you should be worried about while developing mobile applications.
Data Stored on Mobile Devices
In most mobile application designs, it is observed that the mobile device stores or caches some information. Due to limited constraints on the space availability on today's mobile devices architects go ahead and exercise this option. People often default to storing the sensitive information too in clear text. Mobile platforms like Android and iOS are susceptible to rooting or jail breaking, which gives users unrestricted access to the underlying file system. Using this root level access, malicious users or malicious applications can easily retrieve the sensitive information stored on the device.
Weak Cryptography
Data security is another concern when in transit or stored. While choosing to store sensitive data on mobile devices, designers often employ encryption techniques. Few platforms like iOS do provide API's to encrypt data; however, these platforms are yet to get a strong key management technique or protocol. Android too provides APIs for cryptographic primitives, but no built-in protocol for key management. Designers may find themselves having to make decisions about what to use to generate keys, how to use them, and where to store them. Often they end up selecting a strong encryption algorithm, but choose a poor key management protocols. When you have weak cryptography design and keys are stored on the device, shared between users, or hardcoded, they do not provide adequate protection to the data.
Moving Substantial Business Logic Client Side
Designers tend to move a substantial amount of business logic to mobile devices unaware of it implications. When developing rich client applications, users are given direct access to a particular service, while maintaining a simple and attractive user experience. Incorporating business logic such as password re-verification can often lead to unexpected security issues. Like web based attacks, a malicious attacker could use a simple HTTP proxy that captures requests and responses and alter the response from the server to bypass security controls built in by the application’s logic.
Relying on Client Side Data Validation
In current business scenarios, users need to access enterprise applications both from the web and the mobile devices. Attackers have been abusing the weakness of client-side data validation in web since long time now. Data validation weakness has crept into application development in the mobile application space. Hackers can easily bypass client side data validation by using a proxy between the mobile app and the server.
There’s the old joke about two hunters running from a lion, and the one runner says to the other: we can’t outrun the lion. And his buddy replied, “I don’t have to outrun the lion, I only have to outrun you.” Many, over the years, have applied the same logic to application security: If their software is ‘secure enough’ attackers will move on to easier targets. Mobile application security is an easy target for attackers currently and you need to address security on priority.
The trends already mention mobile apps taking a plight in the financial sector, with online banking, online trading apps. Security, although a prime driver for custom development, is one of the hardest aspects to get right. The industry is starting to see the security & privacy concerns in developing mobile applications. Initiatives and best practices are been released by groups like OWASP that have been addressing mobile security in a big way. There is a need to leverage the native security APIs of the platform, handle sensitive data with care, and choose the right data protection classes for the mobile application architecture. Let us make an attempt to look at few critical weaknesses you should be worried about while developing mobile applications.
Data Stored on Mobile Devices
In most mobile application designs, it is observed that the mobile device stores or caches some information. Due to limited constraints on the space availability on today's mobile devices architects go ahead and exercise this option. People often default to storing the sensitive information too in clear text. Mobile platforms like Android and iOS are susceptible to rooting or jail breaking, which gives users unrestricted access to the underlying file system. Using this root level access, malicious users or malicious applications can easily retrieve the sensitive information stored on the device.
Weak Cryptography
Data security is another concern when in transit or stored. While choosing to store sensitive data on mobile devices, designers often employ encryption techniques. Few platforms like iOS do provide API's to encrypt data; however, these platforms are yet to get a strong key management technique or protocol. Android too provides APIs for cryptographic primitives, but no built-in protocol for key management. Designers may find themselves having to make decisions about what to use to generate keys, how to use them, and where to store them. Often they end up selecting a strong encryption algorithm, but choose a poor key management protocols. When you have weak cryptography design and keys are stored on the device, shared between users, or hardcoded, they do not provide adequate protection to the data.
Moving Substantial Business Logic Client Side
Designers tend to move a substantial amount of business logic to mobile devices unaware of it implications. When developing rich client applications, users are given direct access to a particular service, while maintaining a simple and attractive user experience. Incorporating business logic such as password re-verification can often lead to unexpected security issues. Like web based attacks, a malicious attacker could use a simple HTTP proxy that captures requests and responses and alter the response from the server to bypass security controls built in by the application’s logic.
Relying on Client Side Data Validation
In current business scenarios, users need to access enterprise applications both from the web and the mobile devices. Attackers have been abusing the weakness of client-side data validation in web since long time now. Data validation weakness has crept into application development in the mobile application space. Hackers can easily bypass client side data validation by using a proxy between the mobile app and the server.
There’s the old joke about two hunters running from a lion, and the one runner says to the other: we can’t outrun the lion. And his buddy replied, “I don’t have to outrun the lion, I only have to outrun you.” Many, over the years, have applied the same logic to application security: If their software is ‘secure enough’ attackers will move on to easier targets. Mobile application security is an easy target for attackers currently and you need to address security on priority.
Thursday, March 17, 2011
Simple Autocomplete
IRCTC - India's Rail Ticket Booking Website which is sought to be a secure platform for the citizens booking their tickets has few simple security configurations missing.
An example is the auto-complete not set to off on their payments page - a practice which most of the secure web applications follow for sensitive pages right from login page. Below is a snapshot.
An example is the auto-complete not set to off on their payments page - a practice which most of the secure web applications follow for sensitive pages right from login page. Below is a snapshot.
Tuesday, March 15, 2011
Past few months
Readers,
For the past few months or rather lemme say a year, I haven't been actively writing out here. I have been spending my time on other security aspects of my life. I secured myself from being a bachelor (got married :D), secured my Post Graduation (completed my Executive Management from IITB) and secured my job too. :)
Interestingly am back into security work doing a product development in space of data privacy. There have been many trends that I have been watching and techniques which I have learnt. Will be sharing via blog posts often now.
For the past few months or rather lemme say a year, I haven't been actively writing out here. I have been spending my time on other security aspects of my life. I secured myself from being a bachelor (got married :D), secured my Post Graduation (completed my Executive Management from IITB) and secured my job too. :)
Interestingly am back into security work doing a product development in space of data privacy. There have been many trends that I have been watching and techniques which I have learnt. Will be sharing via blog posts often now.
Monday, November 01, 2010
OTP adoption from India to the US?
One Time Password (OTP) is a password that is valid for only one login session. It is a popular authentication mechanism in India. It is essentially in use with Banking and Stock Broking Apps to do a two-factor authentication. SMSes on your registered mobile phone is been predominantly used as a medium to accomplish this second factor of authentication.
Recently, Facebook announced to users that they now have the option of texting "otp" to 32665 from any U.S. mobile phone to receive an OTP via SMS that is good for 20 minutes of log-in time to their Facebook account.
Nice to see Facebook working on the security front for once rather than endless feature updates. It has had its fair share of security woes so it’s nice to see they are doing something which I think may be genuinely useful for it’s burgeoning user base.
In India, a lot of banks use a similar way called Transaction Authorization Code. A OTP when you want to carry out a transaction which involves moving money out from your account (bill payment, fund transfers etc).
This method can provide security but it will not eliminate hackers from getting access to Facebook account. Using non secured network without encryption and other security measures will get the situation back to square one.
It would be also nice if you had security like GMail account security feature, which provides the information if there is a connection opened on my account from another location and monitor all latest ip’s logged into the session.
Recently, Facebook announced to users that they now have the option of texting "otp" to 32665 from any U.S. mobile phone to receive an OTP via SMS that is good for 20 minutes of log-in time to their Facebook account.
Nice to see Facebook working on the security front for once rather than endless feature updates. It has had its fair share of security woes so it’s nice to see they are doing something which I think may be genuinely useful for it’s burgeoning user base.
In India, a lot of banks use a similar way called Transaction Authorization Code. A OTP when you want to carry out a transaction which involves moving money out from your account (bill payment, fund transfers etc).
This method can provide security but it will not eliminate hackers from getting access to Facebook account. Using non secured network without encryption and other security measures will get the situation back to square one.
It would be also nice if you had security like GMail account security feature, which provides the information if there is a connection opened on my account from another location and monitor all latest ip’s logged into the session.
Monday, June 28, 2010
Getting Hands Dirty with Ettercap Tool
Over last few weeks, I have been fiddling around with this tool to test one of the applications. I found the tool has some real good capabilities. Sniffing over a switched network is not easy. However, using Ettercap, I managed it quite nicely.
In an Ethernet network computers communicate with each other via Ethernet MAC addresses. So, there is a mechanism needed for matching of IP addresses with the addresses in an ethernet network. The mechanism is called ARP (Address Resolution Protocol).
What ARP does is exactly what most people do, when they have to find Mr. X in a crowd of people - they shout loud enough, so that everyone can hear them and expect Mr. X to answer, if he is there. When he answers, we will know who is he. When ARP wants to know whats the Ethernet address matching a given IP address it uses an Ethernet technic, called BROADCASTING, with which the datagram is addressed to all the workstations in the network. The broadcast-datagram sent by ARP contains a request for the IP address. Every computer, received that request compares the requested address with its own IP address and if they match, it sends an ARP reply back to the asking computer. After rreceiving the reply, the asking computer can get the Ethernet address of the computer it is looking for, from his reply. After the computer finds an Ethernet address, he stores it in its ARP cache (ARP table), so he won't need to look for it the next time he wants to send a datagram to the same address. However, it is not good this information to be stored forever (the Ethernet adapter of the other host may be replaced for some reasonm and the entry for the computer's IP in the ARP cache will become invalid). So the entries in the ARP cache expire after a period of time. Most operating systems will replace an entry in their ARP cache even if they haven't sent and ARP request before. That allows a MITM (Man-In-The-Middle) attack to be performed.
Wednesday, March 10, 2010
About the 'Rugged' Initiative
As most of the readers on my blog would be knowing, the Security experts in February launched a new effort to ensure software is written from the ground up with security in mind -- a philosophy and message they're aiming at people outside of the security industry.
The Rugged Software Development initiative is basically a foundation for creating resilient software that can stand up to attackers while performing its business or other functions.
A couple of years back, I remember posting a blog article, if basic security mantras could be incorporated in the Computer Science & IT Courses in Universities. Here is the link to the same: http://smartsecurity.blogspot.com/2008/04/can-security-be-incorporated-in.html . I was happy that to learn that 'Rugged' did have this as a part of its initiative. Question is, "When will Indian Universities understand and incorporate the same?" The Indian IT industry spends so much on training costs, as more than 70% of fresh graduates are not employable/productive right away.
This isn't the first industry effort to push developers to bake security into their code. There have been several before like: Homeland Security's Build Security In guidelines, Microsoft's Software Development Lifecycle (SDLC) framework and tools, Building Security In Maturity Model (BSIMM), where financial services firms are comparing notes and sharing their secure coding strategies and experiences and OpenSAMM (Software Assurance Maturity Model), an open-source model aimed at becoming an industry standard for secure software development.
Rugged doesn't include any new frameworks for secure coding, however, and instead will serve as an "on-ramp" for secure software development, Rugged is different because it's aimed at people outside of the security realm. Rugged is specifically targeted at people out of the security context.
Getting the secure software development message to the masses won't be easy, and the plan is to get some initial support and momentum from the application security industry.
Unfortunately, most developers don't know what it means to write secure code, and worse they think they already write secure code if they write high quality code. Software security practitioners have struggled to get past this mindset.
Rugged code is a way of breaking through and instilling a mindset that secure code should be a pride-of-ownership issue just as much as elegant, high performing, and high quality code is.
The Rugged Software Development initiative is basically a foundation for creating resilient software that can stand up to attackers while performing its business or other functions.
"It's more of "a value system" for writing secure software, versus a compliance program, according to its founders,who hope to incorporate the tenets of rugged code development into computer science programs at universities."
A couple of years back, I remember posting a blog article, if basic security mantras could be incorporated in the Computer Science & IT Courses in Universities. Here is the link to the same: http://smartsecurity.blogspot.com/2008/04/can-security-be-incorporated-in.html . I was happy that to learn that 'Rugged' did have this as a part of its initiative. Question is, "When will Indian Universities understand and incorporate the same?" The Indian IT industry spends so much on training costs, as more than 70% of fresh graduates are not employable/productive right away.
This isn't the first industry effort to push developers to bake security into their code. There have been several before like: Homeland Security's Build Security In guidelines, Microsoft's Software Development Lifecycle (SDLC) framework and tools, Building Security In Maturity Model (BSIMM), where financial services firms are comparing notes and sharing their secure coding strategies and experiences and OpenSAMM (Software Assurance Maturity Model), an open-source model aimed at becoming an industry standard for secure software development.
Rugged doesn't include any new frameworks for secure coding, however, and instead will serve as an "on-ramp" for secure software development, Rugged is different because it's aimed at people outside of the security realm. Rugged is specifically targeted at people out of the security context.
Getting the secure software development message to the masses won't be easy, and the plan is to get some initial support and momentum from the application security industry.
Unfortunately, most developers don't know what it means to write secure code, and worse they think they already write secure code if they write high quality code. Software security practitioners have struggled to get past this mindset.
Rugged code is a way of breaking through and instilling a mindset that secure code should be a pride-of-ownership issue just as much as elegant, high performing, and high quality code is.
Tuesday, January 26, 2010
Plenty of (IN)Secure Broadband Routers
SShh.....The Problem of Default Passwords for the Wireless Routers still exists in most parts of the country. The Mumbai terror attacks did bring in a concern for people using Wireless Networks and not have secured them. However, time and again I have been still snooping into the so-called 'Secured' Wireless Networks because the routers admin password is still set to default. Crazy !!
BSNL, the most widespread broadband provider, supplies its own ADSL Router which is been configured by the BSNL line-man. Since most of the broadband customers are not so tech-savy, they understand very little about the technical configuration done in the Wireless Routers.
YOU and I know that default configuration of the broadband router is insecure. We may be good guys, may be the bad guys too. The default login to the router's admin console via username: admin and password admin is very silly to get into the broadband connection. The encryption security or the password key provided has not much of security to be provided now.
3 things that I see from this point:
a) Can the end-users be educated about the 'french-latin' of router security?
I assume Success Rate as very low
b) Can the Internet Service Provider person configure a 'lockdown' version of Secure Routers?
I assume Success Rate as low to moderate
c) Can the router device manufacturers start providing warning messages if their devices are running on default passwords?
I assume Success Rate as moderate
Any comments are welcome !!
YOU and I know that default configuration of the broadband router is insecure. We may be good guys, may be the bad guys too. The default login to the router's admin console via username: admin and password admin is very silly to get into the broadband connection. The encryption security or the password key provided has not much of security to be provided now.
3 things that I see from this point:
a) Can the end-users be educated about the 'french-latin' of router security?
I assume Success Rate as very low
b) Can the Internet Service Provider person configure a 'lockdown' version of Secure Routers?
I assume Success Rate as low to moderate
c) Can the router device manufacturers start providing warning messages if their devices are running on default passwords?
I assume Success Rate as moderate
Any comments are welcome !!
Mumbai to Host India’s First e-Crime Forum
On the 23rd and 24th February, a leading cyber crime security event, e-Crime India, will be staged in Mumbai for the first time. With the support of OWASP India, Data Security CounciI of India (DSCI) and The Institution of Electronics and Telecommunication Engineers (IETE), the forum will be hosted at Hotel Novotel, Juhu Beach, Mumbai.
India’s foremost cyber crime experts and IT security professionals will convene to address the key challenges faced by the people whose job it is to tackle e-crime in India and issues connected with electronic risk. Internationally renowned Cyberlaw expert, Mr. Paven Duggal, will deliver a special address to the forum. Chief information security officers from leading banks, including Bank of India, ICICI, State Bank of India, Standard Chartered and HSBC, and global corporations such as Vodafone, Walt Disney, and Reliance Life, will join him on the podium. The forum will also hear presentations from leading academics and high-ranking law enforcement officials, including the senior inspector of police at Mumbai’s cyber police station.
Over 250 senior decision makers from business, government, and law enforcement are expected to attend the event, which is being sponsored by organisations including HDFC Bank and Websense.
As one of the most rapidly developing countries in the world, India has seen an enormous increase in internet users in recent years and accordingly e-crime in India has grown at an increasingly alarming rate, costing the Indian economy an estimated $50 billion annually.
e-Crime India is a major initiative and is the newest member of the e-Crime Congress family of events following e-Crime Middle East, which was hosted in Abu Dhabi, December 2009. The e-Crime Congress, hosted annually in London attracting over 550 professionals from over 40 countries, recognises the need for international cooperation. Peter Brady, Business Development Manager of AKJ Associates, who organise the forum, says: ‘we are very happy to be coming to India, because cyber crime is a truly worldwide problem that is of concern to everyone. The e-Crime Congress has established a global reputation over the past eight years for its cutting edge agendas that deliver key information on the latest e-crime threats and practical guidance for overcoming them. We take pride in bringing together the right people to share information and combat cyber crime around the world collectively.’ Manoj Saha, Managing Editor of Dickenson Intellinetics, who are partnering AKJ Associates for e-Crime India, added: ‘as an organisation deeply involved with events related to financial markets, private equity and investment banking, e-crime India is a natural value adder to professionals in the Indian banking, corporate and financial markets - we are delighted to partner with AKJ Associates in making e-crime India the destination event that no security professional should miss.”
Click Here For Complete Details of Event: http://www.e-crimecongress.org/india/
Sunday, December 20, 2009
Latest Phishing Site of ICICI Bank
Hi All,
I just came across a phish email created for ICICI Bank Users.
Sharing the screen-shots for fun. Have reported the fake site to antiphishing.org
The 'Phish' email:
I just came across a phish email created for ICICI Bank Users.
Sharing the screen-shots for fun. Have reported the fake site to antiphishing.org
The 'Phish' email:
Phishing Site Link: http://adamthompson.org/infinity.update/BANKAWAY.sessionid/update;RetUser/Y&AppSignOn.icicibank.co.in/index.html
Thursday, October 08, 2009
Application security should be addressed in initial SDLC stages
IT applications are akin to the organization's blood vessels because they carry critical information and execute key processes. However, due to a peripheral approach to security, application security is often neglected.
Applications require strong embedded security to prevent breaches. Hence enterprises should start to address security at the software development lifecycle's (SDLC) early stages. There are several ways to go about this.
Education: Because business users or customers are often unaware about security risks, developers and the application architect should be familiar with possible security threats and application attacks. These personnel should inculcate the application security culture throughout the lifecycle.
If you estimate risk correctly from the beginning, it will also help you to save on costs. According to an industry statistic, if the cost of fixing a bug at design phase is X, post the release it would cost 60X. The cost of fixing bugs increases during each stage of application development. Developers can be trained on dummy applications to help them learn how attackers operate.
Build a threat model: A threat model for your application is essential to identify the involved risks, possible attack scenarios, controls and risk mitigation costs. To start, you should understand the application's utilization. You can categorize an application based on usage (internet or intranet), data sensitivity (sensitive or non-sensitive) and the technology used (web based or non-web based application). These parameters help you categorize the application security level as high, medium or low. Based on this classification, security controls are integrated during the application design process.
Read more on SearchSecurity.TechTarget.IN >>
Applications require strong embedded security to prevent breaches. Hence enterprises should start to address security at the software development lifecycle's (SDLC) early stages. There are several ways to go about this.
Education: Because business users or customers are often unaware about security risks, developers and the application architect should be familiar with possible security threats and application attacks. These personnel should inculcate the application security culture throughout the lifecycle.
If you estimate risk correctly from the beginning, it will also help you to save on costs. According to an industry statistic, if the cost of fixing a bug at design phase is X, post the release it would cost 60X. The cost of fixing bugs increases during each stage of application development. Developers can be trained on dummy applications to help them learn how attackers operate.
Build a threat model: A threat model for your application is essential to identify the involved risks, possible attack scenarios, controls and risk mitigation costs. To start, you should understand the application's utilization. You can categorize an application based on usage (internet or intranet), data sensitivity (sensitive or non-sensitive) and the technology used (web based or non-web based application). These parameters help you categorize the application security level as high, medium or low. Based on this classification, security controls are integrated during the application design process.
Read more on SearchSecurity.TechTarget.IN >>
Friday, September 25, 2009
Can your Exchange Administrator view your mailbox
Hi All,
I have been trying hard to figure out whether the Microsoft Exchange 2007 Administrators can view a user's mailbox? If so, how is this audited?
Unfortunately, I believe there is no real way of doing this in Exchange Server 2007. The closest you'll get would be to experiment with diagnostics logging settings on MS Exchange IS Private and then trolling the application event log for the events created when someone logs onto a secondary mailbox. But as yet, I haven't heard of anyone who has figured out a way to do this which meets typical audit requirements.
In Exchange 2003, I know we could do this very well. Just go to:
https://exchange2003/exchange/username
Put in our administrator user/pass, and login to that users mailbox and you could view his/her mailbox.
Interesting thingi isn't it??
I have been trying hard to figure out whether the Microsoft Exchange 2007 Administrators can view a user's mailbox? If so, how is this audited?
Unfortunately, I believe there is no real way of doing this in Exchange Server 2007. The closest you'll get would be to experiment with diagnostics logging settings on MS Exchange IS Private and then trolling the application event log for the events created when someone logs onto a secondary mailbox. But as yet, I haven't heard of anyone who has figured out a way to do this which meets typical audit requirements.
In Exchange 2003, I know we could do this very well. Just go to:
https://exchange2003/exchange/username
Put in our administrator user/pass, and login to that users mailbox and you could view his/her mailbox.
Interesting thingi isn't it??
Friday, August 28, 2009
No Built-In Response.HTMLEncode in Java
Why doesn't Java have a built-in HTMLEncode function??
With security vulnerabilities like Cross-Site Scripting (XSS) luring around since so many years, I am wondering why hasn't Java yet come up with its own function for Encoding chars which are malicious.
Developers have to rely on either writing their own functions to encode characters to prevent XSS or use Open-Source libraries available to encode.
I believe 'Sun' ... sorry...'Oracle' should think of having this simple thing built-in.
What say folks?
With security vulnerabilities like Cross-Site Scripting (XSS) luring around since so many years, I am wondering why hasn't Java yet come up with its own function for Encoding chars which are malicious.
Developers have to rely on either writing their own functions to encode characters to prevent XSS or use Open-Source libraries available to encode.
I believe 'Sun' ... sorry...'Oracle' should think of having this simple thing built-in.
What say folks?
Friday, July 31, 2009
Dev Tools for Security Testing
I have been realizing that even the development tools can be good for initial security testing !!
Let me explain what I mean by this.
For instance, I have been working on a highly sensitive application (in defense sector) and this is a supposedly a Thick Client application. Developed using Windows Forms and the latest technologies of Messaging, this application can be tested for security by the development tool like Visual Studio features itself.
Most of the security testing include Data Validation checks. Input Validation, Output Validation, SQL Injection, etc are few checks related to data validation. These checks can be done using the Visual Studio IDE itself where the values for the application can be changed and checked if the application passes the validation check.
Simple Steps in a Typical Scenario:
1. My dev teams says they have performed the validation both at the client-side and server-side code to ensure application security. However, this needs to be checked.
2. So, if I pass valid values at the application client side, debug the application at server-side to change the values passed to check if the server-side validation actually fires the validation, my job is done.
3. Why would I choose such a method? because typically other than application sending request over HTTP, it is "really" tough to intercept the request sent from the client machine to the server and modify the request parameters for security mis-use cases.
IMO, close to 60% security checks could be easily done by using the dev tools debug features itself and it proves really useful if the application sends requests in non-HTTP protocol.
Let me explain what I mean by this.
For instance, I have been working on a highly sensitive application (in defense sector) and this is a supposedly a Thick Client application. Developed using Windows Forms and the latest technologies of Messaging, this application can be tested for security by the development tool like Visual Studio features itself.
Most of the security testing include Data Validation checks. Input Validation, Output Validation, SQL Injection, etc are few checks related to data validation. These checks can be done using the Visual Studio IDE itself where the values for the application can be changed and checked if the application passes the validation check.
Simple Steps in a Typical Scenario:
1. My dev teams says they have performed the validation both at the client-side and server-side code to ensure application security. However, this needs to be checked.
2. So, if I pass valid values at the application client side, debug the application at server-side to change the values passed to check if the server-side validation actually fires the validation, my job is done.
3. Why would I choose such a method? because typically other than application sending request over HTTP, it is "really" tough to intercept the request sent from the client machine to the server and modify the request parameters for security mis-use cases.
IMO, close to 60% security checks could be easily done by using the dev tools debug features itself and it proves really useful if the application sends requests in non-HTTP protocol.
Friday, July 24, 2009
Botnet Attack Details from Kaspersky
One of the good folks over at Kaspersky Lab, Yury Namestnikov, has written a great white paper about the worldwide botnet “industry.” The story was picked up by Computer Weekly which did a good summary of it.
The financial “highlights” of the ill-gotten gains from botnets (From Computer Weekly):
• Hiring a botnet for DDoS attacks costs from $50 to thousands of dollars for a continuous 24-hour attack.
• Stolen bank account details vary from $1 to $1,500 depending on the level of detail and account balance.
• Personal data capable of allowing the criminals to open accounts in stolen names costs $5 to $8 for US citizens; two or three times that for EU citizens.
• A list of one million email addresses costs between $20 and $100; spammers charge $150 to $200 extra for doing the mailshot.
• Targeted spam mailshots can cost from $70 for a few thousand names to $1,000 of tens of millions of names.
• User accounts for paid online services and games stores such as Steam go for $7 to $15 per account.
• Phishers pay $1,000 to $2,000 a month for access to fast flux botnets.
• Spam to optimize a search engine ranking is about $300 per month.
• Adware and malware installation ranges from 30 cents to $1.50 for each program installed. But rates for infecting a computer can vary widely, from $3 in China to $120 in the US, per computer.
And what makes this all possible? There are tens of millions of PCs available to botnet operators because of bad computer security on machines in homes and bad security practices by the people who use them.
Computer Weekly story: “Kaspersky reveals price list for botnet attacks”
Original white paper here. “The economics of Botnets”
The financial “highlights” of the ill-gotten gains from botnets (From Computer Weekly):
• Hiring a botnet for DDoS attacks costs from $50 to thousands of dollars for a continuous 24-hour attack.
• Stolen bank account details vary from $1 to $1,500 depending on the level of detail and account balance.
• Personal data capable of allowing the criminals to open accounts in stolen names costs $5 to $8 for US citizens; two or three times that for EU citizens.
• A list of one million email addresses costs between $20 and $100; spammers charge $150 to $200 extra for doing the mailshot.
• Targeted spam mailshots can cost from $70 for a few thousand names to $1,000 of tens of millions of names.
• User accounts for paid online services and games stores such as Steam go for $7 to $15 per account.
• Phishers pay $1,000 to $2,000 a month for access to fast flux botnets.
• Spam to optimize a search engine ranking is about $300 per month.
• Adware and malware installation ranges from 30 cents to $1.50 for each program installed. But rates for infecting a computer can vary widely, from $3 in China to $120 in the US, per computer.
And what makes this all possible? There are tens of millions of PCs available to botnet operators because of bad computer security on machines in homes and bad security practices by the people who use them.
Computer Weekly story: “Kaspersky reveals price list for botnet attacks”
Original white paper here. “The economics of Botnets”
Thursday, June 18, 2009
Isn't that Impossible?
Not every organization and their people know about software security issues nor do they respect the same.
In most of my workshops conducted with developers for secure coding, I often hear the proclamation, "Isn't that Impossible..." and then the drama starts...
Many developers do not understand how the web works
• “Users can’t change the value of a drop down”
• “That option is greyed out”
• “We don’t even link to that page”
Many developers doubts attacker motivation
• “You are using specialized tools; our users don’t use those”
• “Why would anyone put a string that long into that field?”
• “It’s just an internal application” (in an enterprise with 80k employees and a flat network)
• “This application has a small user community; we know who is authenticated to it” (huh?)
• “You have been doing this a long time, nobody else would be able to find that in a reasonable time frame!”
Many developers do not understand the difference between network and application security
• “That application is behind 3 firewalls!”
• “We’re using SSL”
• “That system isn’t even exposed to the outside”
Many developers do not understand a vulnerability class
• “That’s just an error message” (usually related to SQL Injection)
• “You can’t even fit a valid SQL statement in 10 characters”
Many developers cite incorrect or inadequate architectural mitigations
• “You can’t execute code from the stack, it is read-only on all Intel processors”
• “Our WAF protects against XSS attacks” (well, clearly it didn’t protect against the one I’m showing you)
Developer cites questionable tradeoffs
• “Calculating a hash value will be far too expensive” (meanwhile, they’re issuing dozens of Ajax requests every time a user click a link)
There would be dozens more. The point that is developer education for security is one of the largest gaps in most SDLCs. How can you expect your developers to write secure code when you don’t teach them this stuff? You can only treat the symptoms for so long; eventually you have to attack the root cause.
In most of my workshops conducted with developers for secure coding, I often hear the proclamation, "Isn't that Impossible..." and then the drama starts...
Many developers do not understand how the web works
• “Users can’t change the value of a drop down”
• “That option is greyed out”
• “We don’t even link to that page”
Many developers doubts attacker motivation
• “You are using specialized tools; our users don’t use those”
• “Why would anyone put a string that long into that field?”
• “It’s just an internal application” (in an enterprise with 80k employees and a flat network)
• “This application has a small user community; we know who is authenticated to it” (huh?)
• “You have been doing this a long time, nobody else would be able to find that in a reasonable time frame!”
Many developers do not understand the difference between network and application security
• “That application is behind 3 firewalls!”
• “We’re using SSL”
• “That system isn’t even exposed to the outside”
Many developers do not understand a vulnerability class
• “That’s just an error message” (usually related to SQL Injection)
• “You can’t even fit a valid SQL statement in 10 characters”
Many developers cite incorrect or inadequate architectural mitigations
• “You can’t execute code from the stack, it is read-only on all Intel processors”
• “Our WAF protects against XSS attacks” (well, clearly it didn’t protect against the one I’m showing you)
Developer cites questionable tradeoffs
• “Calculating a hash value will be far too expensive” (meanwhile, they’re issuing dozens of Ajax requests every time a user click a link)
There would be dozens more. The point that is developer education for security is one of the largest gaps in most SDLCs. How can you expect your developers to write secure code when you don’t teach them this stuff? You can only treat the symptoms for so long; eventually you have to attack the root cause.
Looking for better solution(s)
It's been 5 years that I have been looking over Application Security issues. It makes me wonder when I find myself and many others still looking out for some unsolved or better security solutions. Certain issues where we have broken our heads to get a solution, but at the end it hasn't been "enough" secure.
I thought it might be interesting to post my list of such issues for others to see things and get opinions on the same.
Still Looking for better (Secure) solutions for following points:
1. Implementing a strong Key Management solution for PCI Compliance. Customers trust products which can help achieve this compliance, however do not trust the bespoke implementation. I strive to get this done !!
2. Develop a better CAPTCHA mechanism to defend robots. A believe a real world user hates the current image version displayed. It has to be simple and secure.
3. Get the NAT'ed IP address of the user using HTML or Javascript.
4. Strong solution to prevent users from getting on to fake sites (Phishing) without much of user education.
5. Developing an Effective and Manageable Web Application Firewall which can be at least a bronze bullet (if not a silver bullet) for Web Security. :)
6. Designing security for social networking sites where a feature could be exploited to be a flaw.
I thought it might be interesting to post my list of such issues for others to see things and get opinions on the same.
Still Looking for better (Secure) solutions for following points:
1. Implementing a strong Key Management solution for PCI Compliance. Customers trust products which can help achieve this compliance, however do not trust the bespoke implementation. I strive to get this done !!
2. Develop a better CAPTCHA mechanism to defend robots. A believe a real world user hates the current image version displayed. It has to be simple and secure.
3. Get the NAT'ed IP address of the user using HTML or Javascript.
4. Strong solution to prevent users from getting on to fake sites (Phishing) without much of user education.
5. Developing an Effective and Manageable Web Application Firewall which can be at least a bronze bullet (if not a silver bullet) for Web Security. :)
6. Designing security for social networking sites where a feature could be exploited to be a flaw.
Monday, May 04, 2009
My Top Excuses for Not Fixing Security Defects
Here are the TOP excuses/reasons I have come across from people who would not want to fix a critical or severe security defect:
1. Functionality is prioritized before security.
"Doesn't matter if the application can be accessed by unauthorized users, but the application should be working as we need to GO LIVE !!"
2. Ahh !! We do not need to be compliant to that level of security.
"Lack of basic security measures required for an application."
3. The application will be replaced soon with newer systems. Why bother to change now??
"The system owners with no concrete plan of replacing the system in next phase pounce with this excuse for not fixing the defects at this moment."
4. The security solution is conflicting with the business requirement.
"Remember the requirement is to email the password to the user in clear text. Ahh !! a defect in requirement itself."
5. Inadequate reach of security risk to the customer.
"The software vendor realizes the importance of security and the risks involved, but unfortunately his Point of Contact at the Customer side is a non-technical guy who doesn't realize the importance equally and denies a change."
1. Functionality is prioritized before security.
"Doesn't matter if the application can be accessed by unauthorized users, but the application should be working as we need to GO LIVE !!"
2. Ahh !! We do not need to be compliant to that level of security.
"Lack of basic security measures required for an application."
3. The application will be replaced soon with newer systems. Why bother to change now??
"The system owners with no concrete plan of replacing the system in next phase pounce with this excuse for not fixing the defects at this moment."
4. The security solution is conflicting with the business requirement.
"Remember the requirement is to email the password to the user in clear text. Ahh !! a defect in requirement itself."
5. Inadequate reach of security risk to the customer.
"The software vendor realizes the importance of security and the risks involved, but unfortunately his Point of Contact at the Customer side is a non-technical guy who doesn't realize the importance equally and denies a change."
Tuesday, April 21, 2009
Microsoft Security Intelligence Report v6
Microsoft has released the latest version of the Microsoft Security Intelligence Report (SIRv6), examining industry-wide software vulnerability disclosures, Microsoft vulnerability disclosures and exploits, malicious software (malware), and potentially unwanted software.
I understand that some of you may not wish to read a 150 page technical analysis document, except as a way to fight off insomnia. Because of that, if you go over to the main SIR page at www.microsoft.com/sir, there is also a "Key Findings" document that is much more concise and provides a nice summary of the findings from each section.
Report: http://www.microsoft.com/security/portal/sir.aspx
Subscribe to:
Posts (Atom)