Subscribe to receive all latest blog updates

Microsoft SQL database optimization is a constant struggle for any project, and this is something that Apriorit tackles often as an R&D outsourcing company. The thing is, when developing an application, initially engineers tend to point all their attention towards actually writing the code, while performance takes the back seat. Often, performance problems are caused by the speed at which the data from the application is received. Some problems can creep past the MVP stage and only became apparent when your solution is fully released to the general public.

This guide will cover certain ways to detect restart or shutdown of the PC, as well as other similar events, such as log off or sleep. We will be handling the OS shutdown event using WinAPI for different types of applications - console, GUI applications, and services. If you’re interested in the general information on Windows process monitoring, you can also check out this article.

In this article you will find a short overview of I/O completion ports (IOCP), as well as a simple C++ implementation of copying folder with files by using I/O requests. We hope that this guide will prove useful for anyone with basic C++ and Windows API experience and will help them learn the basics and certain specifics of WinAPI IOCP programming.

Mac OS X 10.4 saw the introduction of a new kernel subsystem that proves itself very useful when it comes to managing authorization from the kernel. This subsystem is called Kernel Authorization, or Kauth. It can be used to modify any authorization decisions, which proves very useful for creating anti-viruses, and other security software, as well as for general system access when needed. In this article we will show you two examples of using Kauth subsystem – blocking access to certain files and directories, and listening for mounting and unmounting of specific devices. Both examples will involve creating kernel extension that will use Kauth in order to listen for specific events.

Since its introduction over 2 years ago, Swift gathered a lot of feedback, both positive and negative, and quickly established itself as a popular new iOS app programming language, as well as a great tool to write software for various Apple products. There are a lot of reviews on the Internet comparing Swift vs Objective-C and trying to determine the pros and cons of each language.

This tutorial provides you with easy to understand steps for a simple file system filter driver development. As a result, obtained demo driver is intended to print names of open files to debug output.

This article would be interesting for developers with basic Windows driver experience as well as C/C++ knowledge. In addition, it could be also useful to people without Windows driver development deep understanding.

Web app vulnerabilities, as every developer knows, are a never-ending programming cat and mouse game with would be attackers. While there are too many security issues at times to count, keying in on those that continue to surface year in and year out we feel is an appropriate place to start.

Apriorit is an outsourcing company, focused on providing managed, dedicated R&D teams to both startups, as well as Fortune 500 industry leaders. Security has always been one of our core areas of expertise from the very beginning, yet at the same time, we count on extensive experience developing web applications for our clients. In this article we decided to share some of this experience and tackle the problem of how to avoid web app vulnerabilities. While there are scanner tools that can help you with the basic vulnerability assessment, the best way to ensure that an app is free of any vulnerabilities is to build it from the ground up with best security practices in mind. Since the topic itself is so broad, we decided to focus on three common examples that we will discuss in detail, communicate where the problem lies, and how you can avoid it. The Big 3 we will focus on in this article are: 1) Security Misconfiguration; 2) Broken session and authentication management; and 3) Cross-Site Request Forgery (CSRF).

Security Misconfiguration

A nasty threat, security misconfiguration can happen on a range of levels of an application stack. The platform, application servers, web server, database, framework and custom code can all be vulnerable. At a threat level, anonymous, external attackers can certainly be to blame but so can users that possess their own accounts who are steadfast in their desire to interfere in the system. Insiders especially who are seeking to disguise their actions are also in play.

From an exploitability standpoint, it is actually quite easy for an attacker to gain entry to things like unused pages, unpatched flaws, default accounts, as well as unprotected files and directories. Data recovery costs can be quite expensive when dealing with this specific application vulnerability, as the system can be fully compromised in some instances with data either stolen completely or altered at a snail’s pace over time.

So we ask you, is your application vulnerable? To begin, if your software is out of date (including but not limited to OS, DBMS, code libraries, Web/App Server and applications) then you could be subject to common web based application vulnerabilities. Next, consider engaging in these tested, prevention/solution steps to protect against security misconfiguration:

  1. Remove the demo and sample code that come with web applications tools as they can   provide a known target for potential attackers.
  2. Eliminate features, plugins and web pages that are unused.
  3. Turn off configuration and setup page access, and do not leave these pages available for potential attackers to access.
  4. Do not share passwords between accounts, and do not occupy the same administration accounts and settings across Production, Test and Dev systems.
  5. It is recommended to secure all layers on an individual basis and within all levels within an application.
  6. Turnoff debugging – this will ensure that internal information is not relayed back in response to errors or test queries.
  7. Ensure folder permissions are set correctly, and disable directory browsing.
  8. The starting position (for security) should be that by default, everything is off. Least privilege is recommended and the only features that should be activated are those that are needed for the application to run.
  9. Contract an external penetration test company. Internal scans and audits are always needed, but an external testers should definitely be considered.
  10. Subscribe to security site RSS feeds to stay up-to-date on the best security practice.

Broken session and authentication management

Similar to common vulnerabilities such as security misconfiguration, threat agents for broken session and authentication management can also be external hackers, users with their own accounts, as well as insiders. Statistics show that a typical attacker will prey upon authentication or session management flaws to in turn impersonate users. It is nasty work and the tools to achieve this can be through unprotected passwords, accounts or session IDs.

Custom authentication and session management schemes are commonly built by developers, but constructing them correctly is a whole other issue, as we all well know. Flaws to detect exploit lie in logout password management, remember me, account update, timeouts and similar such areas. The implementation is unique so finding the countermeasures to protect against these specific web application vulnerabilities is difficult to say the least.

The technical impact of these web application security vulnerabilities as they pertain to broken session and authentication management can be quite severe. For example, if the flaw gives way to some or potentially all accounts, in 2016 that hacker will have the tools to literally do what he/she desires. Privileged accounts are thus easy to exploit.

The larger question, how do you know if you’re vulnerable, and then of course, how to avoid web app vulnerabilities with respect to broken session and authentication management? Some key questions first to ask are:

  1. Within the URL, are session IDs exposed?  
  2. When warehoused via hashing or encryption, are credentials continuously protected?     
  3. Can users log out and do session IDs timeout?
  4. Post log-in, is a rotation of session IDs occurring?
  5. In regards to TLS connections, are credentials (session IDs and passwords among others) sent over them?

It should be blatantly obvious that the principal assets a developer needs to protect to prevent these types of common web application vulnerabilities in 2016 are credentials and session IDs. One of the first things developers should do is make sure that SSL is put in place for all of the authenticated parts of the particular application. Moreover, credentials should be verified that they are being stored in a hashed form.

At the design stage developers can go a long way in also preventing these vulnerabilities. For example, not writing your own session handlers and instead using only the native session management mechanism. Nor should home-grown cookies be used for session-management or authentication. A single authentication mechanism should be used and once a user authenticates, a brand new session cookie should be issued coupled with the invalidation of the previous session cookie. This step in particular will put a stop to session hijacking attacks.

Some other design steps that can be taken are verifying every application page contains a logout link that can be easily identified. Also, shorter timeouts for inactive sessions are a must. Making sure the user actually knows their old password before activating a new one, not sending credentials, such as user name, over channels such as email, and not exposing session identifiers in the URL (session token for example).  

Cross-Site Request Forgery (CSRF)

When talking about web application security issues and solutions, CSRF frequently arises. From a solution standpoint there are clear countermeasures one can take and tools to prevent it. Basically, anyone who can input content into your users’ browsers and then oblige them to put forth a request to your website is a threat. For example, a website or HTML feed that users have access to could in theory do this.

So how does this work? An attacker would come up with false HTTP requests thus conning the victim into submitting these via XSS or image tags for example. If in fact the user is deemed valid, that attack of course succeeds. The principal security weakness here is the fact that browsers send credentials (session cookies and others) in an automatic fashion, potential attackers can in turn put together web pages which can run forged requests that are impossible to differentiate from legitimate ones. An attacker can thus trick a victim into making changes such as updating account details or even making purchases.

To avoid web app vulnerabilities associated with CSRF one method is to add a random value to the body of each form that is performing a sensitive transaction or processing sensitive data. This particular function will generate a long value (random) and connect it to the form as a concealed input field (named _RequestVerificationToken). The cookie will have the same value and name and the requisite security flags that will stop JavaScript from accessing it. 

Next, on the server you can place a code that will check for the presence of this same random value. To complete this you need to add a ValidateAntiForgeryToken feature to the ChangePassword action that in turn will process the form POST. This ValidateAntiForgeryToken action is the final action required to prevent CSRF attacks. Once executed it will begin to perform a number of checks, such as:

  1. Validation that a _RequestVerificationToken parameter and cookie are present.
  2. Corroboration that the values (of the two inputs) are neither null nor empty.
  3. Validation the values match, and is cryptographically authorized to belong to the logged in user.

Should any of the above fail, the request will stand as rejected. This works because with the addition of the random _RequestVerificationToken factor to the ChangePassword form, a potential attacker has a new, third value that they in turn will have to submit as an integrated part of their request.

 

While our Big 3 is just that, three real big threats, the good news is the solutions and countermeasures we laid out are implementation friendly and something our engineers have a lot of experience working with. Staying on top of similar threats is a matter of staying keyed in, and up to date. We hope that this article gave you a good idea on how to make your web applications more secure.

 

In terms of software, reverse engineering is the process of researching programs to obtain some closed information and algorithms of their work. While software reversing results can be used for legal purposes, it is generally considered that they are used by hackers for illegal activity. For example, researched algorithms can be the base to develop a license key generator (program crack). In the modern world, almost any software uses network data exchange. Such software product can be researched for vulnerabilities, which can be then used to get unauthorized access to a remote computer.

This article includes description of simple unhooker that restores original System Service Table hooked by unknown rootkits, which hide some services and processes.

Contents:

1. Rootkit detection algorithm
2. Memory-mapped files in kernel mode
3. Implementation of the antirootkit algorithm
4. SST unhooker demonstration
5. Anti-rootkit building