When developing for mobile, applications often have to request some permissions from the system. They might need access to the user's contacts, to the Bluetooth connection or the ability to send SMS messages. All of the permissions mentioned above are platform permissions, defined by the Android framework.

But there are cases for when these don't suffice and the application needs to define their own custom permission. I'll use our own company as an example. Secure Code Warrior might create an app that saves some private data as part of a profile, including the user's performance on the SCW platform. And we would like to allow another security training app, say DevTrainer, to use this data if the user gives them permission to do this. This is sensitive data, the user certainly wouldn't want just anybody to know this, but the SCWApp shouldn't completely hide and protect it as it might be useful. So we wish to let the user have control over it. This is where custom permissions come in.

The SCWApp creates a custom permission, DevTrainer requests this permission and the user can decide whether he wants to allow this or not. This is a common practice and a good way to restrict access to white-listed applications.

Unfortunately, there are some unintuitive behaviors around custom permissions which makes them risky from a security standpoint. Concrete, custom permissions can be defined by any app at any time, and "first one wins", and this strategy comes with some consequences.

For the following scenario, we define two app profiles which we introduced above (all of these applications are fictional for demonstrative purposes):

1. SCWApp: the app that defines a custom permission and defends a component using this permission.

2. DevTrainer: this app defines the same permission as SCWApp and declares to the user that it wishes to hold this permission.

This is a common scenario coined the Peer Apps Case. If the DevTrainer app was just a plugin for the SCWApp it would not have to define the custom permission. The assumption, in this case, is that SCWApp would be installed before DevTrainer and no unexpected behavior will happen. If somehow the user does install DevTrainer first, the user is not informed about the request for the permission. If the user then later installs SCWApp, DevTrainer is not retroactively granted the permission, so the DevTrainer app's attempts at using the secured component will fail.

This is where the Peers App Case comes in. In some cases, you cannot expect one app to be installed before the other. Say if Facebook and Twitter both want to use each other's components, they have to define each other's custom permissions.

However, this is where it gets tricky. If the DevTrainer app is installed first, the user is not informed about its request for the custom permission. At this point, even though the user was not informed, DevTrainer holds the custom permission and can access the secured component.

It gets even trickier. The DevTrainer app can change the permissions protection level. Android does not use the defender's protection level but the protection level that is defined first, meaning whichever app was installed first can define it. This means that if DevTrainer changes the permission level to normal, then any future apps that request this permission will not have to be confirmed by the user but are automatically granted access.

This scenario was inspired by the explanation for this problem found on the cwac-security github.

The "first one wins" strategy has some dangerous consequences and not knowing its behavior might lead the developer to make security decisions based on untrusted input and allow unintended apps to access sensitive data or protected services. To learn more about avoiding security decisions via untrusted input, visit our platform. This behavior was changed as of Android 5.0 (Lollipop). But since currently, more than 22% of Android devices are still running a lower version of Android it is important to mitigate the risks of the original behavior in your app. Check if the permission has already been defined at the first run of your app and take appropriate actions if this is the case to resolve any security risks.

Good luck coding, and see you next week!

By defining custom permissions, an app can share its resources and capabilities with other apps.

https://developer.android.com/guide/topics/permissions/defining.html

A side-channel attack is when a hacker can gather information from the physical implementation of a software system rather than a theoretical weakness in the algorithm or bug in the code of the software.

An example I like to use to make this more clear is a way to do username enumeration. If you want to know what username enumeration is or why it is bad, visit our website for a video explanation or play a challenge to see if you can identify it in code.

Now in order to understand how username enumeration can be done through a side-channel attack, you need to have some understanding of how passwords are (or at least should be) handled in modern web applications. A good web application doesn't know your password, it doesn't save or store your password anywhere. So how does it know that what you typed is correct and in fact your password? Well, your password is hashed.

A hashing function is a mathematical operation that is easy to perform one way (although somewhat computationally expensive) but very difficult to reverse and for good hashing algorithms, the output is unique depending on the input. When you register on a website, that hash is stored safely, not your password itself. That means that every time you log-in, the web application hashes your input and compares the hashed results to the stored hash. If you want to learn more about secure password storage, you can do that on our platform.

Hashing input takes some time on a computer and developers always try to optimize everything they write in order for the users to have a smooth experience. One thing that speeds up the program is to skip the hashing when it is not needed. For example, when the username does not exist (and so no password needs to be checked) they can respond to the user immediately. This way they can skip the slow computation of hashing the password. If the username was correct they will hash the password input and compare that to the stored hash.

At this point, you might have guessed where things can go wrong. Even though in reality the hashing takes only a few milliseconds, a hacker can use this added delay to find out if the username he entered was correct or not since a wrong username will have a slightly faster response because no hashing was done. This type of side-channel attack is called a timing attack and it is a good example for how different non-functional requirements can counteract each other. Sometimes code cannot be fast and secure at the same time.

So even though the passwords are handled perfectly, and the message that is displayed is generic and does not advise whether the password or username was incorrect, the system is still vulnerable. The solution is easy, always hash the password or delay sending the reply the time it would take to hash.

The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.

https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

Deleting files on a computer system is tricky. Everybody, even your mother, has deleted a file too many before and has been happy to find it still in the trash and able to recover it.

Data in computer systems is represented by a sequence of bits. That means the system needs to do some bookkeeping within the file system to know which bits represent which file. Among this information is the size of the file, the time it was last modified, its owner, access permissions and so on. This bookkeeping data is stored separately from the contents of the file.

Usually, when a file is removed nothing happens to the bits representing the file, but the bookkeeping data is changed so that the system knows this part of the storage is now meaningless and can be reused. Until another file is saved in this location and the bits in this location are overwritten, you can often still recover the data that was saved. This not only improves the speed of deleting files but is often a useful feature to undo the deletion.

However, there are downsides to this approach. When an application on a computer system handles sensitive information it will save this data somewhere on the file system. At some point, when the information is no longer needed, this data may be deleted. If no extra care is taken this data may still be recoverable even though the intention of the developer was that all data was deleted.

The easiest way to completely erase that data is to rewrite the file content with random data (sometimes even several times over). There are several existing methods of secure file removal and they vary across storage types and file systems such as the Gutmann method. However, for day to day application use, these are a bit overkill and you can just overwrite the data yourself.

Be careful though! Do not use all zeros or other low entropy data. Many filesystems may optimize writing such sparse files and leave some of the original content. It is recommended to generate securely random data to overwrite the entire file contents before deleting the file itself.

Data remanence is the residual physical representation of data that has been in some way erased. After storage media is erased there may be some physical characteristics that allow data to be reconstructed.

https://fas.org/irp/nsa/rainbow/tg025-2.htm

BSIMM 8 is out! Fantastic. The one and only large-scale study on what security practices large organizations put in place to produce secure software.

The study is carried out by application security professionals under the supervision of Gary McGraw, making sure the gathered data is consistent, accurate and gives an insight into what 300,000 developers do on a day-to-day basis.In my latest presentation, I reference BSIMM numbers where I mention that on average, there are 2 application security professional per 100 developers.

However, that hasn't been the case since BSIMM4. BSIMM8 reports that this number is even less, now at 1.6 per 100 developers. Hiring more application security professionals will simply not work as there is a shortage of talent. More than ever, we need to give the developers the tools and the training to write secure code that is hands-on, readily available and scalable for organisations.

The report also shows that the most common activity in the Training practice is providing an awareness training to all employees at 67%. I started mapping what we do at Secure Code Warrior (SCW) in the Training practice and realized that our solution can tick off all the 12 activities in the Training practice ranging from level 1 (most companies do it) to level 3 (very few companies do it).

One single solution that can be used to cover an entire practice!Out of the 12 training practices, the most interesting practices for the Secure Code Warrior solution are:

• Level 1: Provide awareness training
• Level 1: Deliver on-demand individual training
• Level 2: Enhance satellite through training (SCW metrics)
• Level 3: Reward progression through curriculum (SCW badges)
• Level 3: Provide training for vendors or outsourced workers (SCW Assessments)
• Level 3: Host external software security events (SCW Tournament mode)
• Level 3: Identify satellite through training (SCW metrics)

Are you confident that your current solution addresses these practices?

Why does one developer application security training program produce better results than another?

Over my 10+ years as a SANS trainer and the last three years founding and building Secure Code Warrior (SCW), I have seen the value of investing time and resources into making training programs produce the best results.

In our first year of selling, our company engaged over 10,000 developers in secure code training, and I noticed a number of trends among those who had the most effective roll-out. Their results are heart-warming: great engagement, security awareness boost and strong ROI of the program by catching security weaknesses earlier before they become expensive.

I hate to admit it, but there have also been a few who took the "low-effort" approach and tried to roll out a program by sending an email with a link to the training. Not surprisingly, it doesn't fare as well and we had to correct these roll-outs.

Below, I am sharing what I believe are five important lessons that will significantly enhance the engagement levels, impact and success of any developer security training program, including ours.

1. Put some fun into the kick off if you want your program to have impact

Making a special kick-off day event, or giving your program a movie/geeky/gaming theme can make a big difference to the level of excitement and participation from the start. One of our large customers has created a whole fantasy program around a popular TV series, with t-shirts, badges and stickers, making the whole training program an experience no developer would want to miss. Another themed their event around Star Wars, held conveniently on the 4th of May. A bit of fun goes a long way to helping employees get on board, making short bursts of important developer secure code skills training feel like break from work, rather than another task that needs to be done. Milestone #1 achieve, we've got their attention and they know about the program.

2. Find the right developer security training champion (hint: they need communications skills more than security skills!)

Being able to find the right security champions in each scrum team is critical to ongoing program success, especially in larger organisations. In my experience, not all highly-skilled security or developer experts have highly developed people and/or communication skills. The best security champions, those who will give your program positive on-going impact, are those people who are passionate about security and have strong people, influencing and communication skills. Choose wisely and take personality and communication skills into account.

3. Have cool rewards that recognise skills

In general, every computer geek " including developers - like to be recognised for their intelligence and skills. When you reward them with specific status stickers, geeky gadgets, special badges or custom printed t-shirts that recognise their skills, they will wear or display them with pride. If someone achieves something significant in the training program, it is important to think of ways to give them recognition and exposure. I saw a great initiative with one customer who regularly took photos of their Secure Code Warrior champions and posted them alongside a photo and message from the company's CISO in the employee newsletter.

4. Don't try and make your developers into security experts

While you want to make your developers the "first line of defense" in your security program by helping them to code securely, that doesn't mean they need to be the most in-depth security experts in your business; or that you should continuously push new security vulnerabilities and data breach examples to them. While security is important, their primary objective is often building a great product or service and following the pace of the business. If you overload someone with too much security,  you run the risk of disengaging them. Key lessons learned, they need to understand basic security hygiene and support them with tools to code securely, but they don't need to be the company security expert.

5. Don't measure the training, measure the impact

Don't measure how many hours of training your developers take or how many videos they watch, measure the number of weaknesses that get picked up in the development life-cycle through code analysis, bug-bounties or classic vulnerability testing before your start the program in each team.  If your training program is working, the number of vulnerabilities being identified will go down. The second thing to measure is the time it takes to fix a vulnerability. If it takes a developer a month to fix it, this clearly shows they don't understand how to do it, but if they can fix it in an hour, you know they master the skills. These are the two metrics that clever companies are employing to measure the impact of their developer secure coding training.

5 important lessons on how to roll out effective developer security training:

1. Put some fun into the kick off if you want your program to have impact
2. Find the right developer security training champion (hint: they need communications skills more than security skills!)
3. Have cool rewards that recognise skills
4. Don't try and make your developers into security experts
5. Don't measure the training, measure the impact

Researchers from VirginiaTech released a paper after analysing hundreds of posts on the most popular developer forum (Stack Overflow). They looked at the type of questions asked around security, the most popular answers given by the community and the effect it has on code software engineers.

Not a real surprise for people who have been in Cyber Security for a while, but more awareness is needed around this problem from a developer perspective:

• Security features provided by coding frameworks (e.g. JAVA Spring) are overly complicated and poorly documented
• A substantial number of developers do not appear to understand the security implications of coding options, showing a lack of cyber security training
• Many of the suggestions and "fixes" on these forums are not secure but were getting positives votes and thus higher in ratings

The report suggests the following solutions:

• Workforce retraining
• Semi-Automating security bug detection and fixing

We need to make security easy for developers and built-in from the start in order to maintain the speed in which businesses operate today.

"The significance of this work is that we provided empirical evidence for a significant number of alarming secure coding issues, which have not been previously reported," the paper says. "These issues are due to a variety of reasons, including the rapidly increasing need for enterprise security applications, the lack of security training in the software development workforce, and poorly designed security libraries."

https://www.theregister.com/2017/09/29/java_security_plagued_stack_overflow/

Earlier this month Belgian bug bounty hunter, Inti De Ceukelaire disclosed a creative hack that affects hundreds of companies. The trick involves exploiting faulty business logic in popular helpdesk and issue trackers to gain access to intranets, social media accounts or most often Yammer and Slack teams. You can read about the details on Inti's own blog post. I was impressed by the creativity needed to come up with this exploit and curious about the process involved, so I decided to ask Inti some questions, and I'm sharing his answers with you.

Hello Inti, can you briefly introduce yourself to our readers?

I'm Inti, bug bounty hunter at Intigriti and Hackerone. I live in Aalst (Belgium) and spend my days breaking stuff.

Last week I read your blog post about what you have since called 'Ticket Trick' and I was impressed by your creativity to find this exploit. How did you come up with the idea to try out this trick?

I participate in bug bounty programs, which means that certain websites offer money to responsible security researchers that discover unique vulnerabilities. As there's a lot of competition, you need to keep looking for stuff others haven't already found. I thought Slack was an interesting attack vector because it often holds sensitive information and sometimes only requires a valid company e-mail. So I grabbed a beer, laid down in the sofa and started thinking about all the possible attack vectors. Suddenly I had this wild idea - and it turned out it worked. I generally try everything that comes into my mind. Even though that only works for a few times, it pays off. ;-)

As someone who is usually working on the opposite side, trying to secure code, I often wonder what a pentesting session looks like.  Where do you work? Is it something you also do in your free time from your couch? Or do you sit in an office?

During the day I work as a digital creative coder at a radio station called Studio Brussel. It involves some programming and some social media, but no security. I try not to mix my hobby with my professional job. I'm afraid I'd lose my creativity if I did. I don't hack that often: maximum a few hours a week. It can be at the table, on the couch or on my bed - whatever is comfortable at that moment.

How do you start? Do you have a cheat sheet? Do you have some inputs to test if there is sufficient input validation or output escaping?

I'm really chaotic so I don't really have a checklist, I just use my gut feeling. Most of the time I start of with something called recon: listing all interesting target information, subdomains, IP addresses, whatever I can find. I try to see the bigger picture and understand the business logic before I even start hacking. If you only look for the standard, text-book vulnerabilities, you'll miss a lot of the more clever and complex flaws. When it comes to input, I try to cover as many vulnerabilities possible in one payload. Whenever I discover something interesting, I play around with it for a while and throw a lot of nonsense into it, just to see how the system reacts to it. The best bugs can often be found in the more remote parts of a web application, so I try to dig as deep as I can.

What do you think makes a good pentester? Any tricks up your sleeve you can share us?

I'm not a pentester so I can't really speak for pentesters in general, but I think motivation and persistence are the most important assets. Most people won't even consider looking for security vulnerabilities in Google because they have the best engineers in the world, yet they pay out millions of bug bounties every year. I'm working on a target for over 2 years and now I'm starting to get to the really interesting bugs. It takes a while. The problem with normal pentesting is that the testers are rewarded a set amount, whether they find critical vulnerabilities or not. I believe there are still plenty of bugs left in Facebook, it just takes someone that is willing to dig deep enough.

When you realized the scale of the Ticket Trick, what was your first thought?

I had mixed feelings. I felt amazed and immediately thought of the bug bounties I could collect with it, but on the other hand I was shocked that this was possible. Whenever you find something like this, you suddenly own a lot of precious information malicious parties would be very interested in. The disclosure process is a tough one: you need to inform as many affected companies as possible, but on the other hand, you need to make sure the information doesn't get leaked or abused.

Why did you decide to release the information before collecting more bounties?

Doing the right thing is more important than collecting bounties. I think I had my fair share and now want to give back to the community. Besides, I've been informing companies about this issue for months, so more and more people knew about it. I didn't want it to get leaked or abused by someone with bad intentions.

How did you feel about the responses from affected companies?

Most of the responses were satisfying. Some companies didn't really care about it, but at the end of the day, it's their loss. Being rejected as a security researcher is part of the game. At least I didn't get any lawsuits. 10 years ago, that probably would've been the case.

One last question, on reddit I read that you claimed $8,000 in bug bounties, do you have any cool plans to spend this money?

In total, I got more than $20,000 from this bug. More than half of it goes to taxes. I spend the rest on normal things like travel trips, going out for dinner, ... nothing crazy. :-)

Thank you very much for your time and good luck hunting in the future!

The bug is still out there. It isn't something that can be fixed right away. Over the past few months, I contacted dozens of companies and affected vendors as part of their bug bounty programs in order to get their setup fixed.

https://medium.freecodecamp.org/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c

If we look at any organization, public or commercial, there are two things we can guarantee. Firstly, their products and services are increasingly digital, which means they involve software developers creating lines of code. Secondly, these digital businesses are under pressure from traditional and non-traditional competitors, operating in a more dynamic and global world.

Within this environment, CIOs have become the new innovators, and are in positions of power and influence. However, strong pressure to accelerate speed-to-market, enhance quality and increase flexibility has led to complex, distributed development teams, with a focus on rapid development of features and functions without cognisance of the vulnerabilities they could be creating.

More than ever before, a new way of working is required. You only need to look at the nuclear damage at Equifax following their recent breach, which was the result of insecure coding. CIOs and CISOs should think carefully about whether their development teams are the first line of risk, or are they the company's security champions, their company's true "first line of defense".

I have created this Secure Coding Checklist to help CIOs and CISOs consider whether you have set your development teams up to be secure coding champions who can help you innovate with faster, better and safer code.

1. Does your C-level executive recognise that traditional network security isn't enough?

Securing the network layer using traditional security measures is no longer sufficient and was rarely successful anyway, even against semi-professional hackers. Among many concurring reports, Verizon's 2017 Data Breach Investigations Report sites that 35 per cent of data breaches today are caused by web application vulnerabilities. Web application security is just as important as network security.

2. Are you thinking about security from the start?

Current application security tools focus on moving from right to left in the Software Development Life Cycle (SDLC). This approach supports detection and reaction, meaning security teams detect the vulnerabilities in the written code and react to fix them. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them when writing code in the IDE. Not to mention the time delays incurred in remedying the issue. Secure code champions start at the extreme left of the SDLC, with a focus on continually training their developers in secure coding, so they can be the first line of defence in their organization, preventing vulnerabilities in the first place.

3. Do you actually build security skills instead of only feeding  knowledge?

Most training solutions (online and in-classroom) focus on building knowledge rather than building skills.  For developers to write secure code, they need regular access to hands-on learning that actively engages them to learn and build their secure coding skills. They need to learn about recent identified vulnerabilities, in real code, and in their own languages/frameworks. This learning experience should help them understand how to locate, identify and fix known vulnerabilities in code.

4. Do you measure your secure coding skills with real-time metrics?

It is important to create evidence that proves to the developer and her organization that a developer's secure coding skills are improving. You can't improve what you cannot measure. Your assessments should help identify the progress of your development teams in real time as well as benchmarking their secure coding strengths and weaknesses.

5. Are you sure your outsourced suppliers apply secure coding  techniques?

Many organization decide to contract out development work to large onshore or offshore development houses. In the best case, the only form of assurance an organization asks on security, is a statement in the contract requiring the deliverable to be "secure". Few actually verify the skills of these development houses upfront and end-up with software that is not following good secure coding practices. The worst case scenario is that they do not know about them and go live with the application.  The most common scenario is they get picked up by dedicated specialists (for which you pay) and you are confronted with either delays in go-live, and contractual discussions on who needs to pay for fixing these security weaknesses. Be smart upfront, and assess the application security skills of the  developers who are going to buid your next application.

6. Are your developers aware of the most common security weaknesses?

85.5% of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities " the OWASP Top 10. Your application security training needs to cover these at minimum and many more vulnerability types. The challenges your developers complete with need to be continuously revised and updated with new challenges for either new coding frameworks or new vulnerability types.

7. Do you have in-house security champions?

Every developer-heavy organization should invest in someone who is going to champion security within your development teams. Their purpose is to be a support point of contact for anyone with questions around security but also to advocate secure coding and secure architecture practices within a team

8. Have you invested in tools for your developers to make secure coding easier?

In an environment with many changes to applications or where agile development is practised, automating parts of security is essential to keep up with the pace and volume. There are tools available at each stage of the development life-cycle that will serve as advisors, quality gates or detection tools. You should have IDE PlugIns that focus on certain types of security bugs and act like spell checkers while the developer is writing his or her code. There are also tools which integrate with the build process that detect certain types of weaknesses when code is being submitted to a code repository. There are also tools which run automated tests over the code, simulating hacking techniques once the software is in production. All have their own set of benefits and challenges, and none can provide a 100% guarantee there are no security issues. The golden rule, the earlier you can capture the weakness, the faster and cheaper it is to remediate the weakness with the least impact on your business.

As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction.  Think twice before you skip this critical capability.

How did your organization go against this checklist?

As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction. Think twice before you skip this critical capability.

Five years ago the Belgian banks banded together to make this fantastic TV commercial, sharing the story of Dave, an extremely gifted clairvoyant who knows some pretty specific personal and financial information. It effectively engaged millions of consumers about the fact that their entire life can be found online and encouraging everybody to be vigilant.

Have a look at the video and you'll see it is even more relevant today than it was in 2012, and we know the consequences are even more frightening.

If you feel like cyber security training is a big headache for your C-suite and employees, involving boring slideshow training, oppressive rules and someone tell you what not to do all the time, it might be a good time to view this video for some creative inspiration.

Watch the video, share it with your human resources and communications teams, and ask them for help to make information security fun again!

It doesn't matter whether you are training the C-suite in cyber security or helping developers in JAVA or C# secure coding skills, there's a place for creativity, gamification and fun.

It doesn't matter whether you are training the C-suite in cyber security or helping developers in JAVA or C# secure coding skills, there's a place for creativity, gamification and fun.