Berezha Secuirty Blog
In response to the global outbreak of COVID-19 caused by the new type of coronavirus, Berezha Security switches to Work from Home mode and postpones all on-site engagements. We assure all our clients and partners that this will not affect the timeliness of project results or any other terms and agreements.
The following months are going to challenge our perceptions of standard business practices and due care. We are doing our best to protect our personnel and secure our clients’ business objectives. The inherent nature of our job allows us to do it remotely, and the architecture of our tools and support systems enable us to do so securely.
We shift our community efforts from IRL events to a series of online experiences we are going to unravel very soon.
We encourage our friends and colleagues in the security industry to follow our example and refrain from office work for as long as possible.
Be safe out there.
Berezha Security is a rather small offensive security consultancy focused around high quality of results and long-term partnerships with every client. However, we find a lot of bugs, too, so we try to keep you up to date with what we find. Last year we listed Top-5 flaws that have let us into the clients’ infrastructure. This year we have decided to publish all the bugs that made us stop all pentesting activities, report the findings, and work with the clients to fix them as soon as possible. We rate this kind of bugs as Critical and deem them as all-stop events, the same way we treat finding an “incident in action” or obtaining access to large amounts of highly-sensitive data. So the bugs that made us freeze in 2019 are.
1. Authentication Bypass
Auth bypass means that it was possible to circumvent the authentication altogether.
Authentication is your application’s first line of defense that protects its functionality and data from basically anyone on the internet. And yes, it is often implemented inconsistently. As a result, attackers could find a way to avoid the burden of providing your app username and password and wreak havoc in an entirely unaccounted manner.
Fixing auth bypass usually narrows down to using a well written, trustworthy third-party authentication component that has been reviewed and tested over time by many security-savvy professionals.
2. Default Password
Sysadmins love default or “standard” passwords. I was an admin once; I know what I’m talking about. Unfortunately, we’ve been through enough pentests to know them all.
Of course, I’m kidding; we don’t remember them all. However, we know the dark places of the internet that list them all. And once we found a password that looks like a “universal” one, we stuff it in each form we have already seen, and each form we find from now on.
Fixing this poor configuration practice is not an easy task since because these passwords are ubiquitous, you never know all the places where they are used.
3. Insecure Direct Object References (IDOR)
It may sound funny to the knowledgeable reader, but yes: id++ is still a thing.
IDOR happens in all sorts of places when you could tweak a request parameter and end up reading (or updating) other user’s data. However, we call an IDOR critical only when we can do it without any authorization. So you can imagine how many other authenticated IDORs did not make this list.
Fixing IDORs is pretty simple in theory: make sure your sessions are valid and mapped to the data and functionality requested by the client. In practice, it is much, much more complicated.
4. Insecure File Upload
Files are dangerous: they can be executable, they can be parsable by unsafe code, and they can contain malicious data. So once you design your app to accept files from the client-side, your attack surface implodes.
And hackers just love uploading files! Once the right data is in the right place, all that’s left to do is triggering its processing. Or – which is way more effective – manipulating an admin user to execute it.
Fixing unsafe file upload can be tricky, but isolating all file-processing functionality in an external garbage container that lives only for a few seconds is usually a good start.
5. Password Hash Disclosure
Password hashes are useful when done right. Passwords should not be stored in clear text anywhere in the system; that is why we have hashes around.
Hashes, in turn, have to be well protected just because once the hackers get them, the only thing required to recover the clear text passwords is time. That is why weak hash disclosure is almost equivalent to password disclosure: a few bucks spent on a GPU instance on AWS do all the heavy lifting of password recovery.
Fixing this kind of issue can be tricky. Still, long before that, at the early stages of application engineering, all passwords should be hashed by so-called “slow” hashing algorithms that prevent fast recovery attacks against the hashed data.
6. Remote Code Execution
This one comes in many forms, and last year we saw like a dozen of those.
Of course, the XML External Entity (XXE) as a first step is still around: reading the file with user credentials, and the rest is history. Certainly, ImageTragick is still a thing, and it is easy to find if you know where to look. Various OS-level and network service bugs were present, no surprise here. What was new, though, is the use of highly-sensitive functionality along with the server-side template parsing. So the Server-Side Template Injection bug that could allow smuggling a Remote Code Execution to the back-end server was an entertaining issue to observe.
Fixing RCEs depends on the root cause of them happening. It is often not apparent at first glance what is causing the vulnerability and where to find it in the code. However, the devastating impact of RCE gives developers enough incentive to do all the analysis and come up with patches.
7. Stored Cross-Site Scripting (XSS)
Well, no surprises here. We found many XSS bugs; some of them were critical.
It means attackers could get access to highly privileged user accounts by merely planting the XSS payloads in various locations in the web application. User to admin XSS bugs are a big deal, so we can’t avoid mentioning them here.
Fixing this kind of bugs could depend on the actual web application functionality. But in general, everything is simple: avoid letting your regular users and your admins share the same application functionality.
8. Unauthenticated Password Change
There is no way to explain how it happens, but it does, and more than once a year. There were a couple of occasions when it was possible to abuse the app logic and reset the user password.
The ways to fix this depend on the context. However, it is always a good idea to follow strict transaction-based logic while implementing security features, such as login and password change, password reset or turning the two-factor authentication on and off.
These are the flaws that we considered critical, and that made us stop the security assessments and jump into helping to fix them. All of these are highly risky and required from attackers little or no specialized knowledge to find and exploit. How come we saw them before the bad guys did? The thing is, we often do not: some clients are learning the truth the hard way. But when we are lucky to do a security assessment before the malicious hackers target the client, the key is to know where to look and to apply the bug hunter’s mindset for the first few days of the project.
If you are interested in testing your application security against our skills, you know where to find us.
Berezha Security provided Application Security training to software developers and got all-five rating on Clutch.
When we are not busy hacking your apps, we promote Application Security knowledge among software development teams. Berezha uses all possible opportunities to do that: our experts run OWASP Kyiv chapter meetups and are involved in the OWASP Ukraine conference organization. We also speak at various IT conferences.
Beyond that, of course, we do corporate training. And one of the groups has just finished the program and has rated us on Clutch with all five stars possible! Thanks, Soft2bet! <3
Berezha Security undertook the task of training the employees of an IT consulting company on security. The goal was to increase awareness of and familiarity with cybersecurity tools.
You can read the full reference on Clutch or get to know more about our training program on our website. To schedule training, contact us.
Dear cybersecurity community, we are happy to start 2020 by opening a position of Penetration Tester in our Kyiv office. To submit your resume, go to https://berezhasecurity.com/#Contact and select ‘‘Work at Berezha” in the contact form. Please make sure you provide a URL to your CV or just send a copy to [email protected]. Although we will carefully review and consider all received CVs, we guarantee an invitation for the interview to the professionals who demonstrated any of the following achievements:
- An Offensive Security certification issued in their name. Please send us a photo of your certificate.
- A 5-years (ISC)2 certification issued in their name. Please provide your membership ID for verification.
- More than 50 points in their account on PortSwigger Web Academy labs. Please send us a screenshot of your position in the Hall of Fame while logged in to the web site.
We will handle the data you provide with the highest discretion. The position opens on March 1, 2020, and we are planning to have a final decision in early February. Berezha Security is a team of security experts that strives to render the highest quality professional services in the market. We are the enthusiasts behind NoNameCon, OWASP Kyiv, CTFs, podcasts, and other gigs you might have heard of. We offer a novel goal-centric working culture and unparalleled team spirit. Are you ready to run with our crew?
We send warm thanks to all our customers and partners: we greatly appreciate the trust you put in us and we will go on doing our best to meet your expectations!
We greatly appreciate the work our team puts into the services we provide and we are proud to have every one of our awesome experts on our side!
And of course, we are the most grateful to the people who have sacrificed their lives, their wellbeing, and their heroic effort to protect our beautiful country and create the opportunity for us to do the job we love. Thank you.
Clutch, a globally-recognized B2B market research firm, recently announced that Berezha Security is listed as an official Clutch Leader among IT and business services providers in Ukraine. This is a major accomplishment for our team, and we’re excited to share this wonderful news with our clients and business partners.
Focus on application security and penetration testing, our in-house experts guide clients through the process of identifying vulnerabilities and enhancing digital products. Most of our customers hire us IT security audits, which often lead to many other services to help them reach their goals. According to Clutch, we are a perfect 5-star rated provider!
To identify leaders in each business segment, Clutch analysts collect and evaluate feedback from clients to understand which companies show a consistent ability to deliver. In some ways, this award is entirely a reflection of how much our clients appreciate us. Check out the following quotes to see what our customers say about us:
“They utilized a number of techniques to find the vulnerable areas of our platform. They were also equipped with recommendations for how to prevent those attacks.” – CTO, Esports Platform
“They had a very effective workflow. The team at Berezha Security was very responsive and finished the testing in time.”– Co-Founder, HR SaaS Company
Berezha Security is also featured on Clutch’s sister sites — The Manifest and Visual Objects. The Manifest, a B2B publication that offers company listings, has us ranked on a directory of technology experts in the field of cybersecurity. Visual Objects, a portfolio site, supplements these lists with images of work samples from projects completed by top cybersecurity firms.
We’d like to take this opportunity to express our gratitude to our incredible clients. We would never have achieved such an important milestone without their support! If you have any interest in joining our network of happy customers, send us a note! We’d love to discuss your security goals.
In one of our previous posts, we wrote about the top 5 ways to get hacked that were extremely popular last year. This post is about the top 5 ways to protect yourself and your customers that companies could benefit from but they don’t.
1. Two-factor authentication
The simplest way to radically increase security is stubbornly ignored by many companies. The “authentication factor” literally means “multiplier”. That is, by adding a second factor (say, a one-time code generated by a mobile application) to the password, you can hypothetically increase the complexity of system hacking by the factor of two.
Even infamous one-time SMS-delivered passcodes, when used together with regular passwords and not instead of them, add a tremendous amount of security for a fairly moderate price. And the vast majority of applications and services, especially corporate ones, have long been allowing users to enable the so-called two-step verification.
But of course, these exercises are too complicated for ordinary users. And our clients will immediately run away to a competitor who doesn’t make their life so hard by forcing them to enter one more value into the web form once every 6 months or so. Let me tell you more: the OWASP Leaders mailing list, which features OWASP chapter and projects leaders, had a lively discussion a couple of weeks ago debating whether or not to force a second factor in this organization’s Google Apps domain. If there are people in the OWASP who question the need for 2FA, what do we want from normal people?
2. Ability to paste from the clipboard into the password field
This is what happens when security decisions are made not by managers but by programmers. It is a disgrace, but in 2019, some banking institutions’ websites still require users to enter the password manually. Password managers? Never heard of them.
Instead of generating a complex and unique 20-character password and automatically inserting it into the form at logon, the client should suffer. They must create the password themselves, keep it in the head, and type in every time they visit the website. In doing so, the customer will miss the keyboard layout or press the wrong key, lock their account, and have to bring their government-issued ID to the bank office to unlock it. Because this is what the programmer’s perception of security looked like.
3. Phishing protection
Two simple steps to protect employees from phishing: enable anti-spoofing emails (by sessing up a few DNS headers) and mark all incoming email messages as EXTERNAL in the Subject field. This will make it more difficult for attackers to fake emails as if they came from your corporate domains, and external phishing from improvised domains and free email services will attract more attention.
As a social engineer, I argue that these actions can protect your staff from phishing attacks by about 95 percent, with the remaining 5 being closed via training and “incident practice”. Unfortunately, it is much easier for many organizations to accuse users of stupidity and to threaten them with punishment for each clicked link.
4. Separation of users from admins
It is difficult for me to imagine the conditions in which in a business environment users may need administrator rights in applications and the operating systems. However, in many organizations, the users are often given at least local admin privileges on their working machine.
Of course, this makes everyone’s life much easier: admins can relax and focus on “the real work,” and users can always install the software and drivers they needed. But this simplification can cause complete company infrastructure compromise due to the hack of just one workplace. And I am not aware of cases where users were deprived of high privileges before such a total incident occurred.
Because all the top managers are local admins on their laptops, so who’s to blame?
5. Separation of networks by destination
All organizations start building their networks not by following the principle of business necessity, but for the reasons of territorial distribution. That is, Kyiv, Lviv and Kharkiv offices, and not the different departments and business functions, get specific subnetworks.
This may seem logical, but in fact, it is another way of least resistance that leads to compromise. After all, different units perform different functions, have different relationships with the outside world, and put the organization at different levels of risk. For example, the IT department selects a new IT solution provider for a long time, then tests it in a virtual lab for months, then deploys it on an isolated network and then gradually opens it to other departments. While the software development department should be able to deploy a new development environment from a template within 10-15 minutes and connect it to its own network, the client’s network, and the wild internet.
Of course, when a less secure network gets compromised and there is no reliable access control policy between it and the other subnets, the incident quickly spreads in all directions and the business stops. While in the case of proper segmentation, the effects of any penetration can be limited to just one business function.
I hope these lines will inspire someone to reconsider their attitude to these issues and change something. But I must admit that the probability of that happening is very small. At least until the next global network virus pops up and puts down half of the Internet.
Startup Security Health Check – a free consulting day from Berezha Security for Ukrainian* startups.
We decided to offer a one-day workshop to Ukrainian startups to test their security level. Free of charge.
The thing with startups is not that they do not spend money on security, but that in their case, it is justified. Startups succeed very rarely, so investing in security early on is entirely unprofitable for them. And when they achieve success, it is usually too late, and they have to redo everything.
The solution to this problem lies on the surface: we have to exclude one variable from this equation – the money. We let Ukrainian startups to spend one day in a company of our software security experts. What can we do in just one day? At least:
- a threat modeling session of the most critical use cases,
- interviews with key developers,
- and a security test of a prototype or MVP.
As a result, the team gets an unbiased picture of their appsec readiness and the security of their product. Why? To avoid having to re-engineer the product before entering a regulated market. To have an answer for security-related questions of potential investors. And to properly evaluate the product’s threats, test the team’s aptness to counter them, and plan for future security investments.
We hope so we can help creative developers encounter fewer pitfalls on their way to success. Take care.
* The service is free of charge for companies with Ukrainian registration.
Based out of Kyiv, Ukraine, our team has completed more than 70 projects and have partnered with 45 clients. We have clients in a wide variety of industries including IT, banking, agriculture, and legal services. No matter what level a company is at with its cybersecurity, it can benefit from external consultation.
Due to our success with our clients, Clutch, a Washington, D.C.-based ratings and reviews firm, has named us as a leader among cybersecurity companies. On the Clutch platform, we have been given a perfect 5.0-star rating!
One of our most recent projects involved conducting a security assessment and testing of a website application for a technology platform. We were given a 5.0 rating by this firm!
We were praised on our ability to stay organized and proactive, all while communicating the progress of our project.
“They’re extremely focused on mitigation and actually provide concrete solutions. Rather than just pointing out where our platform is broken, they offer valuable feedback around how we can fix it,” said the CEO of the platform.
Another one of our satisfied clients is SoftServe, a software development company. We conducted an independent validation of SoftServe’s network. This included penetration testing and an evaluation of the company from a hacker’s perspective.
Again, earned a 5.0 rating. Check out what SoftServe has to say about our partnership below!
“I’m impressed by the Berezha Security’s speed, maturity, and readiness to provide additional advice free of charge,” said the Information Security Director at SoftServe.
Along with our Clutch page, we can be found on Clutch’s sister sites, The Manifest and Visual Objects. The Manifest is a type of business news platform that features us at among the top cybersecurity consultants.
Visual Objects ranks industry leaders according to their Clutch rating, while also posting a portfolio of their previous work.
The entire team at Berezha Security is very thankful for our clients taking the time out of their busy days to provide us with feedback. The reviews we receive help us improve and help expand our network by attracting new clients!
“We appreciate the reviews and value the feedback we get and can use to gradually improve our practices. And it is especially important to every team member to get factual results from the clients directly, and the reviews are a great channel for that,” said Vlad Styran, Co-Founder of Berezha Security.
If your company could benefit from an increase in cybersecurity or you would like to know more about our services, contact us today!
Among Ukrainian organizations, we get the most requests from IT companies, and in this post, I want to talk about some accumulated experience. Quite possibly, it will be useful to other organizations in this business, and maybe organizations from different sectors. So if you know a CIO/CTO from an IT-firm, show them this text. It was written for them.
The IT companies request security services by their initiative in about one of ten cases. In other cases, the reason for such a request is a requirement of the customer or potential customer. Unlike many of my colleagues, I consider this approach to be quite right, practical, and cost-effective. These companies write the code for their clients. This code, in most cases, benefits their customers and makes the lives of many thousands of people more convenient. Therefore, to require IT companies to take care of security is up to either their customers or their customers’ customers. Some virtual Vlad Styran can be deeply concerned about the sad state of software security, but it would be better if he and his associates founded a local OWASP chapter and made the application security knowledge available in their region. What is exactly what he did.
But, at the same time, the “security” requests from IT companies are a bit chaotic, and here let’s dwell into more detail. I see the cause of it in the dualism of the notion of security in any organization that creates information products or services. On the one hand, there is organizational security: protection of systems, networks, and intellectual property, compliance with local and international regulations, etc. That is, protecting the interests of the business in essence: by not allowing it to go bankrupt and its leaders to end up in jail. On the other hand, there is security engineering: protection of products and services from abuse by unauthorized persons, protection of users and their data from consequences of such abuse, and protection of the business model from both third parties and authorized users (for instance, software licensing and DRM). That is the protection of the product and its ability to turn into profit.
Needless to say, these two types of security are quite different areas of knowledge. Unfortunately, this fact is unknown to way too many leaders. Sometimes this causes application security to fall into the operations security management’s responsibility, which results in a lot of additional friction in the relationship of IT and business. Much less often, software security management is assigned operational security tasks – that’s when the real drama begins. In a fairy tale with a happy ending, in both cases, all actors eventually reach consensus and distribute duties more or less naturally. Otherwise, it sometimes leads to work conflicts, and then everything depends on the diplomacy and professionalism of its participants.
To make life easier for executives of IT firms and their subordinates, I will formulate a simple algorithm for deciding where particular security responsibilities should be placed in an organization.
1. Find out what you are protecting:
A: the firm, with all its assets, personnel, financial secrets, from cybercriminals and the requirements of laws and industry standards,
B: the product/service that the company produces, from cybercriminals and malicious user actions.
A.2. In the first case, trust the security professionals who are engaged in the technical protection of information and organizational security measures. Such specialists normally come from the banking system or IT integrators and distributors. In the past, they usually were the employees of IT operating units: system and network administrators. Sometimes – law enforcement officers.
Keywords: CISSP, CISM, Information Security, Security Administration.
B.2. In the second case, assign the task to the software security professionals. Such specialists are less numerous in the job market and have somewhat different skills. In the past, they were programmers, QA/testers, or started in Application Security. Most likely, they participate in Bug Bounty programs in their free time.
Keywords: OSCP, OSCE, Application Security, Bug Bounty, White-Hat Hackers.
A.3. Methodological recommendations and industry standards (that is, instructions on how to build security when you do not know how to do it) are all over the place. Most likely you will deal with ISO 27001, SOC2, NIST, CIS, or another framework. Take this into account when choosing the management and operational security staff.
B.3. As for software security, there are also recommendations here, but with much fewer standards so far (and in my opinion it’s good). Recommendations can be searched for by the keywords OWASP, SAMM, SDL, NIST. The leaders of the secure development business functions should have not only a general comprehension of these processes but also be able to implement and improve them effectively.
A.4. The involvement of external consultants in the technical and organizational security can take place in many forms, but usually, it is either building something faster than you can do yourself or checking the quality of your security measures. Audit and consulting in this area are quite profitable activities if you understand what I mean. Therefore, you have to be very cautious at all stages of the formulation and implementation of projects, since the scope creeps start at day one, and unaccounted expectations may appear in the final stages.
Keywords: CISA, CISSP, ISO27001LA, ISO27001LI, Penetration Test, Security Audit.
B.4. Involving an external resource in the secure development processes is possible at almost all stages of building the software except for the formulation of the business idea. Design, architecture, planning, implementation, testing, deployment, support, incident response – all these and other phases can be performed in-house or outsourced. But this is a thing: at a particular stage of the project development, the existence of internal application security function will become much more efficient. Independent security testing and ad-hoc consulting services are likely to remain helpful from time to time, but in the process of developing, refining and integrating a product, your software security specialist or even an entire unit will become relevant.
Keywords: OWASP, OSWE, OTG, ASVS, SAMM, Application Security Assessment, Application Penetration Test.
5. The placement of a security unit in the organizational structure is a complex and dramatic theme. Many advocates of “good practices” in security management insist that Chief Information Security Officer (CISO) subordination to the CIO is a bad idea, as this creates a conflict of interest: the IT director pursues the availability and performance of systems and services when the security leader imposes a bunch of restrictions on them. In the case of organizational security, this statement might be appropriate, but when it comes to the subordination of security to the CTO in a product organization, the conflict disappears, because it is the CTO who is interested in the security of developed services and products.
Hopefully, these notes will help you navigate the subject and select the right strategy. Or at least save a bit of time. Take care.
Contact Us to Know More!
+1 (315) 303 2323
+380 (44) 364 7336
6 Nimanska St., 41, Kyiv, Ukraine 01103
77 Sichovykh Striltsiv St., Kyiv, Ukraine