• Search for:
    23May, 2023
    Information disclosure vulnerabilities

    In this section, we’ll explain the basics of information disclosure vulnerabilities and describe how you can find and exploit them. We’ll also offer some guidance on how you can prevent information disclosure vulnerabilities in your own websites.

    Learning to find and exploit information disclosure is a vital skill for any tester. You are likely to encounter it on a regular basis and, once you know how to exploit it effectively, it can help you to improve your testing efficiency and enable you to find additional, high-severity bugs.

    What is information disclosure?

    Information disclosure, also known as information leakage, is when a website unintentionally reveals sensitive information to its users. Depending on the context, websites may leak all kinds of information to a potential attacker, including:

    • Data about other users, such as usernames or financial information
    • Sensitive commercial or business data
    • Technical details about the website and its infrastructure

    The dangers of leaking sensitive user or business data are fairly obvious, but disclosing technical information can sometimes be just as serious. Although some of this information will be of limited use, it can potentially be a starting point for exposing an additional attack surface, which may contain other interesting vulnerabilities. The knowledge that you are able to gather could even provide the missing piece of the puzzle when trying to construct complex, high-severity attacks.

    Occasionally, sensitive information might be carelessly leaked to users who are simply browsing the website in a normal fashion. More commonly, however, an attacker needs to elicit the information disclosure by interacting with the website in unexpected or malicious ways. They will then carefully study the website’s responses to try and identify interesting behavior.

    What are some examples of information disclosure?

    Some basic examples of information disclosure are as follows:

    • Revealing the names of hidden directories, their structure, and their contents via a robots.txt file or directory listing
    • Providing access to source code files via temporary backups
    • Explicitly mentioning database table or column names in error messages
    • Unnecessarily exposing highly sensitive information, such as credit card details
    • Hard-coding API keys, IP addresses, database credentials, and so on in the source code
    • Hinting at the existence or absence of resources, usernames, and so on via subtle differences in application behavior

    In this topic, you will learn how to find and exploit some of these examples and more.

    Read more

    How to find and exploit information disclosure vulnerabilities

    How do information disclosure vulnerabilities arise?

    Information disclosure vulnerabilities can arise in countless different ways, but these can broadly be categorized as follows:

    • Failure to remove internal content from public content. For example, developer comments in markup are sometimes visible to users in the production environment.
    • Insecure configuration of the website and related technologies. For example, failing to disable debugging and diagnostic features can sometimes provide attackers with useful tools to help them obtain sensitive information. Default configurations can also leave websites vulnerable, for example, by displaying overly verbose error messages.
    • Flawed design and behavior of the application. For example, if a website returns distinct responses when different error states occur, this can also allow attackers to enumerate sensitive data, such as valid user credentials.

    What is the impact of information disclosure vulnerabilities?

    Information disclosure vulnerabilities can have both a direct and indirect impact depending on the purpose of the website and, therefore, what information an attacker is able to obtain. In some cases, the act of disclosing sensitive information alone can have a high impact on the affected parties. For example, an online shop leaking its customers’ credit card details is likely to have severe consequences.

    On the other hand, leaking technical information, such as the directory structure or which third-party frameworks are being used, may have little to no direct impact. However, in the wrong hands, this could be the key information required to construct any number of other exploits. The severity in this case depends on what the attacker is able to do with this information.

    How to assess the severity of information disclosure vulnerabilities

    Although the ultimate impact can potentially be very severe, it is only in specific circumstances that information disclosure is a high-severity issue on its own. During testing, the disclosure of technical information in particular is often only of interest if you are able to demonstrate how an attacker could do something harmful with it.

    For example, the knowledge that a website is using a particular framework version is of limited use if that version is fully patched. However, this information becomes significant when the website is using an old version that contains a known vulnerability. In this case, performing a devastating attack could be as simple as applying a publicly documented exploit.

    It is important to exercise common sense when you find that potentially sensitive information is being leaked. It is likely that minor technical details can be discovered in numerous ways on many of the websites you test. Therefore, your main focus should be on the impact and exploitability of the leaked information, not just the presence of information disclosure as a standalone issue. The obvious exception to this is when the leaked information is so sensitive that it warrants attention in its own right.

    Exploiting information disclosure

    We’ve put together some more practical advice to help you identify and exploit these kinds of vulnerabilities. You can also practice these techniques using our interactive labs.

    How to prevent information disclosure vulnerabilities

    Preventing information disclosure completely is tricky due to the huge variety of ways in which it can occur. However, there are some general best practices that you can follow to minimize the risk of these kinds of vulnerability creeping into your own websites.

    • Make sure that everyone involved in producing the website is fully aware of what information is considered sensitive. Sometimes seemingly harmless information can be much more useful to an attacker than people realize. Highlighting these dangers can help make sure that sensitive information is handled more securely in general by your organization.
    • Audit any code for potential information disclosure as part of your QA or build processes. It should be relatively easy to automate some of the associated tasks, such as stripping developer comments.
    • Use generic error messages as much as possible. Don’t provide attackers with clues about application behavior unnecessarily.
    • Double-check that any debugging or diagnostic features are disabled in the production environment.
    • Make sure you fully understand the configuration settings, and security implications, of any third-party technology that you implement. Take the time to investigate and disable any features and settings that you don’t actually need.

    Resourse : https://portswigger.net/web-security/information-disclosure

    23May, 2023
    SQL injection

    In this section, we’ll explain what SQL injection (SQLi) is, describe some common examples, explain how to find and exploit various kinds of SQL injection vulnerabilities, and summarize how to prevent SQL injection.

    What is SQL injection (SQLi)?

    SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to other users, or any other data that the application itself is able to access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application’s content or behavior.

    In some situations, an attacker can escalate a SQL injection attack to compromise the underlying server or other back-end infrastructure, or perform a denial-of-service attack.

    SQL injection

    In this section, we’ll explain what SQL injection (SQLi) is, describe some common examples, explain how to find and exploit various kinds of SQL injection vulnerabilities, and summarize how to prevent SQL injection.

    What is the impact of a successful SQL injection attack?

    A successful SQL injection attack can result in unauthorized access to sensitive data, such as passwords, credit card details, or personal user information. Many high-profile data breaches in recent years have been the result of SQL injection attacks, leading to reputational damage and regulatory fines. In some cases, an attacker can obtain a persistent backdoor into an organization’s systems, leading to a long-term compromise that can go unnoticed for an extended period.

    SQL injection examples

    There are a wide variety of SQL injection vulnerabilities, attacks, and techniques, which arise in different situations. Some common SQL injection examples include:

    Blind SQL injection vulnerabilities

    Many instances of SQL injection are blind vulnerabilities. This means that the application does not return the results of the SQL query or the details of any database errors within its responses. Blind vulnerabilities can still be exploited to access unauthorized data, but the techniques involved are generally more complicated and difficult to perform.

    Depending on the nature of the vulnerability and the database involved, the following techniques can be used to exploit blind SQL injection vulnerabilities:

    • You can change the logic of the query to trigger a detectable difference in the application’s response depending on the truth of a single condition. This might involve injecting a new condition into some Boolean logic, or conditionally triggering an error such as a divide-by-zero.
    • You can conditionally trigger a time delay in the processing of the query, allowing you to infer the truth of the condition based on the time that the application takes to respond.
    • You can trigger an out-of-band network interaction, using OAST techniques. This technique is extremely powerful and works in situations where the other techniques do not. Often, you can directly exfiltrate data via the out-of-band channel, for example by placing the data into a DNS lookup for a domain that you control.

    SQL injection

    In this section, we’ll explain what SQL injection (SQLi) is, describe some common examples, explain how to find and exploit various kinds of SQL injection vulnerabilities, and summarize how to prevent SQL injection.

    SQL injection

    Labs

    If you’re already familiar with the basic concepts behind SQLi vulnerabilities and just want to practice exploiting them on some realistic, deliberately vulnerable targets, you can access all of the labs in this topic from the link below.View all SQL injection labs

    What is SQL injection (SQLi)?

    SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to other users, or any other data that the application itself is able to access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application’s content or behavior.

    In some situations, an attacker can escalate a SQL injection attack to compromise the underlying server or other back-end infrastructure, or perform a denial-of-service attack.

    https://youtube.com/watch?v=wX6tszfgYp4%3Forigin%3Dhttps%3A

    What is the impact of a successful SQL injection attack?

    A successful SQL injection attack can result in unauthorized access to sensitive data, such as passwords, credit card details, or personal user information. Many high-profile data breaches in recent years have been the result of SQL injection attacks, leading to reputational damage and regulatory fines. In some cases, an attacker can obtain a persistent backdoor into an organization’s systems, leading to a long-term compromise that can go unnoticed for an extended period.

    SQL injection examples

    There are a wide variety of SQL injection vulnerabilities, attacks, and techniques, which arise in different situations. Some common SQL injection examples include:

    Retrieving hidden data

    Consider a shopping application that displays products in different categories. When the user clicks on the Gifts category, their browser requests the URL:https://insecure-website.com/products?category=Gifts

    This causes the application to make a SQL query to retrieve details of the relevant products from the database:SELECT * FROM products WHERE category = 'Gifts' AND released = 1

    This SQL query asks the database to return:

    • all details (*)
    • from the products table
    • where the category is Gifts
    • and released is 1.

    The restriction released = 1 is being used to hide products that are not released. For unreleased products, presumably released = 0.

    The application doesn’t implement any defenses against SQL injection attacks, so an attacker can construct an attack like:https://insecure-website.com/products?category=Gifts'--

    This results in the SQL query:SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

    The key thing here is that the double-dash sequence -- is a comment indicator in SQL, and means that the rest of the query is interpreted as a comment. This effectively removes the remainder of the query, so it no longer includes AND released = 1. This means that all products are displayed, including unreleased products.

    Going further, an attacker can cause the application to display all the products in any category, including categories that they don’t know about:https://insecure-website.com/products?category=Gifts'+OR+1=1--

    This results in the SQL query:SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

    The modified query will return all items where either the category is Gifts, or 1 is equal to 1. Since 1=1 is always true, the query will return all items.

    Warning

    Take care when injecting the condition OR 1=1 into a SQL query. Although this may be harmless in the initial context you’re injecting into, it’s common for applications to use data from a single request in multiple different queries. If your condition reaches an UPDATE or DELETE statement, for example, this can result in an accidental loss of data.

    LAB

    APPRENTICESQL injection vulnerability in WHERE clause allowing retrieval of hidden data

    Subverting application logic

    Consider an application that lets users log in with a username and password. If a user submits the username wiener and the password bluecheese, the application checks the credentials by performing the following SQL query:SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'

    If the query returns the details of a user, then the login is successful. Otherwise, it is rejected.

    Here, an attacker can log in as any user without a password simply by using the SQL comment sequence -- to remove the password check from the WHERE clause of the query. For example, submitting the username administrator'-- and a blank password results in the following query:SELECT * FROM users WHERE username = 'administrator'--' AND password = ''

    This query returns the user whose username is administrator and successfully logs the attacker in as that user.

    LAB

    APPRENTICESQL injection vulnerability allowing login bypass

    Retrieving data from other database tables

    In cases where the results of a SQL query are returned within the application’s responses, an attacker can leverage a SQL injection vulnerability to retrieve data from other tables within the database. This is done using the UNION keyword, which lets you execute an additional SELECT query and append the results to the original query.

    For example, if an application executes the following query containing the user input “Gifts”:SELECT name, description FROM products WHERE category = 'Gifts'

    then an attacker can submit the input:' UNION SELECT username, password FROM users--

    This will cause the application to return all usernames and passwords along with the names and descriptions of products.

    Read more

    SQL injection UNION attacks

    Examining the database

    Following initial identification of a SQL injection vulnerability, it is generally useful to obtain some information about the database itself. This information can often pave the way for further exploitation.

    You can query the version details for the database. The way that this is done depends on the database type, so you can infer the database type from whichever technique works. For example, on Oracle you can execute:SELECT * FROM v$version

    You can also determine what database tables exist, and which columns they contain. For example, on most databases you can execute the following query to list the tables:SELECT * FROM information_schema.tables

    Read more

    Examining the database in SQL injection attacksSQL injection cheat sheet

    Blind SQL injection vulnerabilities

    Many instances of SQL injection are blind vulnerabilities. This means that the application does not return the results of the SQL query or the details of any database errors within its responses. Blind vulnerabilities can still be exploited to access unauthorized data, but the techniques involved are generally more complicated and difficult to perform.

    Depending on the nature of the vulnerability and the database involved, the following techniques can be used to exploit blind SQL injection vulnerabilities:

    • You can change the logic of the query to trigger a detectable difference in the application’s response depending on the truth of a single condition. This might involve injecting a new condition into some Boolean logic, or conditionally triggering an error such as a divide-by-zero.
    • You can conditionally trigger a time delay in the processing of the query, allowing you to infer the truth of the condition based on the time that the application takes to respond.
    • You can trigger an out-of-band network interaction, using OAST techniques. This technique is extremely powerful and works in situations where the other techniques do not. Often, you can directly exfiltrate data via the out-of-band channel, for example by placing the data into a DNS lookup for a domain that you control.

    Read more

    Blind SQL injection

    How to detect SQL injection vulnerabilities

    The majority of SQL injection vulnerabilities can be found quickly and reliably using Burp Suite’s web vulnerability scanner.

    SQL injection can be detected manually by using a systematic set of tests against every entry point in the application. This typically involves:

    • Submitting the single quote character ' and looking for errors or other anomalies.
    • Submitting some SQL-specific syntax that evaluates to the base (original) value of the entry point, and to a different value, and looking for systematic differences in the resulting application responses.
    • Submitting Boolean conditions such as OR 1=1 and OR 1=2, and looking for differences in the application’s responses.
    • Submitting payloads designed to trigger time delays when executed within a SQL query, and looking for differences in the time taken to respond.
    • Submitting OAST payloads designed to trigger an out-of-band network interaction when executed within a SQL query, and monitoring for any resulting interactions.

    SQL injection in different parts of the query

    Most SQL injection vulnerabilities arise within the WHERE clause of a SELECT query. This type of SQL injection is generally well-understood by experienced testers.

    But SQL injection vulnerabilities can in principle occur at any location within the query, and within different query types. The most common other locations where SQL injection arises are:

    • In UPDATE statements, within the updated values or the WHERE clause.
    • In INSERT statements, within the inserted values.
    • In SELECT statements, within the table or column name.
    • In SELECT statements, within the ORDER BY clause.

    SQL injection in different contexts

    In all of the labs so far, you’ve used the query string to inject your malicious SQL payload. However, it’s important to note that you can perform SQL injection attacks using any controllable input that is processed as a SQL query by the application. For example, some websites take input in JSON or XML format and use this to query the database.

    These different formats may even provide alternative ways for you to obfuscate attacks that are otherwise blocked due to WAFs and other defense mechanisms. Weak implementations often just look for common SQL injection keywords within the request, so you may be able to bypass these filters by simply encoding or escaping characters in the prohibited keywords. For example, the following XML-based SQL injection uses an XML escape sequence to encode the S character in SELECT:

    Second-order SQL injection

    First-order SQL injection arises where the application takes user input from an HTTP request and, in the course of processing that request, incorporates the input into a SQL query in an unsafe way.

    In second-order SQL injection (also known as stored SQL injection), the application takes user input from an HTTP request and stores it for future use. This is usually done by placing the input into a database, but no vulnerability arises at the point where the data is stored. Later, when handling a different HTTP request, the application retrieves the stored data and incorporates it into a SQL query in an unsafe way.

    Second-order SQL injection often arises in situations where developers are aware of SQL injection vulnerabilities, and so safely handle the initial placement of the input into the database. When the data is later processed, it is deemed to be safe, since it was previously placed into the database safely. At this point, the data is handled in an unsafe way, because the developer wrongly deems it to be trusted.

    Database-specific factors

    Some core features of the SQL language are implemented in the same way across popular database platforms, and so many ways of detecting and exploiting SQL injection vulnerabilities work identically on different types of database.

    However, there are also many differences between common databases. These mean that some techniques for detecting and exploiting SQL injection work differently on different platforms. For example:

    • Syntax for string concatenation.
    • Comments.
    • Batched (or stacked) queries.
    • Platform-specific APIs.
    • Error messages.

    How to prevent SQL injection

    Most instances of SQL injection can be prevented by using parameterized queries (also known as prepared statements) instead of string concatenation within the query.

    The following code is vulnerable to SQL injection because the user input is concatenated directly into the query:String query = "SELECT * FROM products WHERE category = '"+ input + "'"; Statement statement = connection.createStatement(); ResultSet resultSet = statement.executeQuery(query);

    This code can be easily rewritten in a way that prevents the user input from interfering with the query structure:PreparedStatement statement = connection.prepareStatement("SELECT * FROM products WHERE category = ?"); statement.setString(1, input); ResultSet resultSet = statement.executeQuery();

    Parameterized queries can be used for any situation where untrusted input appears as data within the query, including the WHERE clause and values in an INSERT or UPDATE statement. They can’t be used to handle untrusted input in other parts of the query, such as table or column names, or the ORDER BY clause. Application functionality that places untrusted data into those parts of the query will need to take a different approach, such as white-listing permitted input values, or using different logic to deliver the required behavior.

    For a parameterized query to be effective in preventing SQL injection, the string that is used in the query must always be a hard-coded constant, and must never contain any variable data from any origin. Do not be tempted to decide case-by-case whether an item of data is trusted, and continue using string concatenation within the query for cases that are considered safe. It is all too easy to make mistakes about the possible origin of data, or for changes in other code to violate assumptions about what data is tainted.

    Resourse : https://portswigger.net/web-security/sql-injection

    10May, 2023
    A Linux NetFilter kernel flaw allows escalating privileges to ‘root’

    A Linux NetFilter kernel flaw, tracked as CVE-2023-32233, can be exploited by unprivileged local users to escalate their privileges to root.

    Netfilter is a framework provided by the Linux kernel that allows various networking-related operations to be implemented in the form of customized handlers. Netfilter offers various functions and operations for packet filtering, network address translation, and port translation, which provide the functionality required for directing packets through a network and prohibiting packets from reaching sensitive locations within a network.

    The Linux NetFilter kernel is affected by a vulnerability, tracked as CVE-2023-32233, that can allow unprivileged local users to escalate their privileges to ‘root,’ potentially leading to the complete compromise of the system.

    “In the Linux kernel through 6.3.1, a use-after-free in Netfilter nf_tables when processing batch requests can be abused to perform arbitrary read and write operations on kernel memory.” reads the advisory. “Unprivileged local users can obtain root privileges. This occurs because anonymous sets are mishandled.”

    The root cause of the problem resides in how tfilter nf_tables handles batch requests, allowing a local authenticated attacker to gain elevated privileges by sending a specially crafted request that causes the corruption of the internal state of Netfilter nf_tables.

    “Netfilter nf_tables allows updating its configuration with batch requests that group multiple basic operations into atomic transactions. In a specific scenario, an invalid batch request may contain an operation that implicitly deletes an existing nft anonymous set followed by another operation that attempts to act on the same nft anonymous set after it is deleted.” wrote Piotr Krysiuk on SecLists.

    Researchers Patryk Sondej and Piotr Krysiuk developed an PoC exploit code that allows unprivileged local users to start a root shell by abusing this vulnerability.

    “That exploit was shared privately with to assist with fix development. Somebody from the Linux kernel team then emailed the proposed fix to and that email also included a link to download our description of exploitation techniques and our exploit source code.” continues Krysiuk. ” Therefore, according to the linux-distros list policy, the exploit must be published within 7 days from this advisory. In order to comply with
    that policy, I intend to publish both the description of exploitation techniques and also the exploit source code on Monday 15th by email to this list. The fix is available from mainline kernel git repository:
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=c1592a89942e9678f7d9c8030efa777c0d57edab “

    The two researchers shared their exploit privately with the Linux kernel team to allow the development of a patch to solve the issue.

    The engineer Pablo Neira Ayuso addressed the flaw by deactivating anonymous set from preparation. phase preventing users to perform any update on it.

    Resource : https://securityaffairs.com/145989/security/linux-netfilter-kernel-flaw.html

    10May, 2023
    GitHub Secret-Blocking Feature Now Generally Available

    GitHub today announced the general availability of push protection, a feature designed to prevent developers from unknowingly exposing secrets in their code.

    Push protection was initially announced in December 2022 as part of secret scanning, a new feature meant to help developers and organizations identify any secrets exposed in their repositories.

    In March 2023, the Microsoft-owned code hosting platform announced the general availability of secret scanning, after previously making it available for free for public repositories.

    Now, the push protection feature is also generally available and is free for all public repositories. It can also be used for private repositories with a GitHub Advanced Security (GHAS) license.

    With push protection enabled, developers are warned as soon as they push a commit containing a highly identifiable secret, and are also provided with guidance on how to remove that secret. As soon as the exposure has been eliminated, the developer can re-push the commit.

    “Push protection only blocks secrets with low false positive rates, so when a commit is blocked, you know it’s worth investigating,” GitHub says.

    The platform is working with service providers to ensure a low false positive rate and is delivering exposure alerts directly in the developers’ IDEs or command line interfaces.

    Push protection, GitHub explains, can be bypassed in urgent circumstances, by providing a reason, such as ‘testing’, ‘false positive’, or ‘acceptable risk’.

    Whenever a bypass occurs, security managers and repository and organization administrators receive an email alert. They can audit all bypasses via audit logs, REST API, alert view UI, and webhook events.

    Push protection can be enabled in the ‘Code security and analysis’ settings, in the ‘Secret scanning’ section. By clicking on the ‘Enable all’ button, both features will be enabled at once.

    “You can automatically enable push protection or provide a custom resource link that will appear in a push protection message via the checkboxes under the ‘Push Protection’ section. This will ensure push protection is applied to any new repository created in your enterprise or organization,” GitHub explains.

    GitHub customers with a GHAS license can also enable push protection on their custom secret patterns.

    Resource : https://www.securityweek.com/github-secret-blocking-feature-now-generally-available/

    8May, 2023
    How to automate security operations effectively and efficiently

    The evolution of security has meant “naming in this space has been an adventure,” and the challenge for cloud vendors has been to provide capabilities while automating and making platforms easy to use, said Rhett Dillingham, vice president security product at security operations provider Sumo Logic.

    Dillingham spoke on the topic at RSA with Adrian Sanabria, a host of Security Software Weekly.

    Sumo Logic’s history has been to make it easy to bring logs in, get initial value, and automate as much as possible, Dillingham said. Part of being a cloud vendor in the security space has meant trying to make platforms “self-service adaptable.”

    Tackling the people aspect of automation

    Security automation has been a big topic for a while now, given the dynamic nature of threats and companies grappling with talent shortages, Sanabria observed. Another issue is the overhead associated with products.

    Even with the benefits automation brings, someone still has to create the automation, make sure a platform works properly, monitor it, fix it if something breaks, and know how to deal with APIs, he noted.

    Automation, Sanabria added, is scary.

    Sumo Logic aims to alleviate the operational aspect of managing security stacks, which frees teams up to derive value from them, Dillingham said.

    As teams work through the end-to-end security operations workflow from collection to detection to investigation response and think about what can be automated in that chain, “there tends to be an over-rotation toward the investigation response portion,’’ he said. So Sumo Logic has focused “on automating as much as possible and investigation by clustering” events into a “refined, true positive alert.”

    The goal is for security teams to be able to easily compile information into the platform, Dillingham said. Sumo Logic last week announced it has integrated the workflow automation portion of its cloud SOAR offering as part of its SIEM. It aims to provide “a stepping stone short of full SOAR adoption” as the next step in automation.

    The idea is once you’ve clustered entity relationships around investigations in triage, now you can automate enrichment into that alert, Dillingham explained. From there, you can do the refining and automate notifications.

    SOAR vs. SIEM

    The two discussed the features of SOAR and SIEM, which came to be defined in security operations in a way that “lumped a few technologies together [and] met your capabilities in a way that has made it unapproachable for a certain segment of enterprises,” Dillingham said.

    Sumo Logic’s goal is to make the incremental steps easier to adopt and utilize, regardless of the nomenclature of what SIEM and SOAR are, he said. “It’s a platform for security operations.”

    Another concern with adopting SOAR technology has been the risk of over-automating beyond what the organizational culture is ready for, specifically, in automated response, Dillingham observed.

    The way Sumo Logic sees it, he said, is you should be automating the work as much as possible to become more efficient. Then you can move into response and make it more iterative so it becomes an efficiency gain.

    Large language models and ChatGPT

    Sumo Logic has also just integrated its SOAR framework into a chat provider of a customer’s choice. That enables them to utilize Q&A and chat capabilities out of the box, he said.

    The platform collects data from a variety of sources and alerts or raw data, so someone can pull in common remediation methods for that technology, for example.

    But Dillingham noted that it is an organizational decision as to whether they are comfortable with the information coming from ChatGPT.

    CISO struggles

    Tool consolidation has become a big pain point for CISOs, Dillingham said. So is the efficiency and efficacy of teams.

    This is why Sumo Logic is aggregating SIEM with SOAR and building a bridge between the two to address the consolidation of alerts coming from the proliferation of tools, he said.

    Resource : https://www.scmagazine.com/native/cloud-security/how-to-automate-security-operations-effectively-and-efficiently

    6May, 2023
    Researcher hijacks popular Packagist PHP packages to get a job

    A researcher hijacked over a dozen Packagist packages—with some having been installed hundreds of millions of times over the course of their lifetime.

    The researcher reached out to BleepingComputer stating that by hijacking these packages he hopes to get a job. And, he seems pretty confident that this would work.

    At least 14 Packagist packages hijacked

    Yesterday, a researcher with the pseudonym ‘neskafe3v1’ reached out to BleepingComputer stating he had taken over fourteen Packagist packages, with one of them having over 500 million installs.

    Packagist is the primary registry of PHP packages that are installable via Composer, a dependency management tool. Rather than hosting these packages though, Packagist serves more as a metadata directory that aggregates open source packages published to GitHub. These packages can then be installed by developers on their machines by running the composer install command.

    The researcher provided proof to BleepingComputer demonstrating that on Monday, May 1, the Packagist pages for these packages were modified to point to the researcher’s (fake) repo, as opposed to the legitimate GitHub repository for each package.

    As an example, here’s how the Packagist page for acmephp package appeared on Monday—with its GitHub link changed to researcher’s repo instead of the authentic github.com/acmephp/acmephp.

    These changes have now been reverted by the Packagist team as checked by BleepingComputer.

    Publishing process on Packagist is a bit different from that on open source repos like npm or PyPI. A developer, as opposed to uploading binaries or software releases directly to Packagist.org, simply creates a Packagist.org account, and “submits” a link to their GitHub repo for a particular package. Packagist’s crawler then visits the provided repo and aggregates all the data to display on the Packagist page for that package.

    When a developer runs Composer with ‘install’ or ‘update’ commands, their Composer instance may first look for the presence of the packages locally, failing which, it defaults to searching on Packagist for this package and retrieving the GitHub URL listed for that package. The contents of the package are then downloaded from this GitHub repo listed on the package’s Packagist page.

    This is in stark contrast to how npm or PyPI works—that is, these registries host and distribute software releases directly from their servers.

    By modifying the Packagist page for each of these packages, the researcher effectively hijacked the installation workflow used within Composer environments. Developers would now get the contents of a package from neskafe3v1‘s GitHub repo, rather than the project’s repository.

    To keep the demonstration to a minimum, the researcher simply changed the composer.json file—something akin to an application manifest, within these packages to read:

    He did so by forking the original project repository, modifying the “description” field within composer.json, and committing the change to his forked repository. At no point did he merge the changes back into the original repository (doing so would have required additional access and possibly invited scrutiny of maintainers).

    Instead, the researcher apparently gained access to the maintainers’ Packagist accounts and changed the GitHub URLs to the listed packags to that of his forked repos. But, he did not reveal the exact method used for hijacking to BleepingComputer.

    When pressed by BleepingComputer to reveal the exact technique that the researcher had used to hijack these packages, we were told this was not a zero-day but a known technique. But we were not told whether the hijack was achieved through, for example, credentials compromise, takeover of maintainer’s email address due to expired domain, or yet another technique:

    “As you can see, I’m looking for a job (that message ‘Ищу работу на позиции…’ means ‘I’m looking for a job…’), so I will disclose a report after I will be hired by some company,” the researcher told BleepingComputer, likening the entire hijacking campaign to “an advertisement of myself as an employee.”

    “Until there is success, there is nothing to talk about.”

    Hijacked via credentials compromise

    In a statement to BleepingComputer, the Packagist team said that no malicious impact had been observed thus far on the platform as a result of this action while confirming the takeover indeed resulted from credentials compromise of maintainer accounts.

    “To our knowledge this has not been used for any malicious purposes and was limited to a few old accounts with insecure passwords and missing 2 factor authentication,” Nils Aderman of Packagist.org, who is also one of the original Composer developers, told BleepingComputer.

    “All four accounts appear to have been using shared passwords leaked in previous incidents on other platforms. Please, do not reuse passwords,” warn Packagist admins.

    “On May 2nd, at 7:21 am UTC we were notified by Juha Suni about the change of URL to multiple Doctrine packages,” further explain the admins in a blog post released today.

    Working alongside Marco Pivetta aka Ocramius, Packagist admins promptly identified all accessed accounts, disabled access to them and restored the GitHub URLs to their former values. The restoration effort was completed by Tuesday morning.

    The researcher additionally told BleepingComputer that he had not abused the technique to distribute malware, but at the same time, said he had not notified either Packagist or the package owners of the little experiment—which raises eyebrows with regards to the ‘ethical’ nature of this research.

    “The only thing I did – I altered ‘description’ field in composer.json files,” said the researcher pointing us to proofs such as Git commits.

    “I’ve just changed the link from github.com/acmephp/core (original) to …my fork. There is no malware, you can diff the original files to mine. I didn’t notify anybody of the attack, neither Packagist admins, nor package owners.”

    In their blog post, Packagist admins request that researchers report bugs and vulnerabilties in a responsible manner.

    “If you are a security researcher and know of a Packagist.org vulnerability or would like to do research on Packagist.org, we ask you to please coordinate testing with us to avoid negative user impact, and to disclose these vulnerabilities responsibly.”

    “You can reach us at security@packagist.org and we reply promptly to all requests or reports. We of course provide credit and publish details of reported vulnerabilities…”

    Resource : https://www.bleepingcomputer.com/news/security/researcher-hijacks-popular-packagist-php-packages-to-get-a-job/

    6May, 2023
    How To Create Seamless Digital Experiences For Web And Mobile

    Before the online market picked up, companies and small retailers always prioritized the customer experience in their stores. The more memorable a customer’s experience is, the more they will return to you and spread the word to their friends and family. But things have changed now.

    According to a survey, over 67% of people have reported that they prefer to make a purchase online rather than offline, especially after the pandemic hit the world in 2019.

    Now the organization has an even more challenging job: how to impress the customer online and improve his experience so that he may get the same feeling as offline but without the personal touch, which played a massive role in the process.

    This is a tricky but doable task. There are simple steps to follow when the organization is developing a web application or needs to lift its digital experience and match a customer’s expectations.

    For this, organizations can leverage manual and automation testing techniques to ensure the online experience is seamless, error-free, and meets customers’ expectations. They can also keep in mind the following best practices to ensure a pixel-perfect digital experience.

    Keep up with the latest trends

    The most important thing to create a seamless digital experience for the web and mobile is to adopt new technologies and trends. These technologies work in two ways for an organization; first, newer technologies are always optimized and more attractive. Second, since competitors start using them, users generally expect them to be on other websites as well.

    For instance, if we just consider the evolution of buttons on a web page, we were somewhere around this:

    Considering we use the older button styles, it might become the first thing a user would notice, and the first impression could make a difference in their perception of our business.

    However, this is just one element of the technology used in the web and mobile applications and is popularly termed as user experience. This expands to animations, transitions, and whatever the user can touch and see on the app that is unique and creative. The second technology that always needs to be kept on par with the latest trends in payment options.

    As per a source,  globally, 67% of buyers preferred credit or debit cards over cash-based transactions. It has been a growing trend worldwide owing to the transparency of transactions and quick refund services.

    By this statistic, we can implement credit and debit card channels and never need to bother about any changes to our /payment URL. But things change drastically when we move from region to region.

    For instance, US citizens prefer credit and debit services. As per the research by Fintech, more than 76% of Indian citizens prefer the UPI payment method, and it is a relatively newer technology than card services. So, as an organization, more than just maintaining our user experience is required.

    If the user’s preferred payment system is unavailable depending on the region, that could be counted as a bad experience.

    Involve user interaction as minimally as possible

    Applications and web development trends have all leaned towards reducing a user’s interaction as low as possible. For instance, advertisement agencies take cookies to determine a user’s interest and show them ads from various websites. This generates enormous revenue for them, but that is just because users click on these ads.

    When we talk about minimal interaction, we consider two things. The first thing is how much a user types, scrolls, and clicks to achieve what he intends to.  The second thing is how much navigation they do to reach from the home screen to the final objective, which in the case of an eCommerce website is considered as “a purchase done successfully.”

    Recently artificial intelligence has started to get involved in almost everything that requires prediction, deduction, or mathematical calculation, such as classification. The most obvious benefit of incorporating artificial intelligence is the reduction in the work done by the user.

    For instance, earlier users were required to search for everything by typing words in the search box. Today, they can tap the microphone icon and speak out their search query.

    Artificial intelligence has also been involved in chatting with customer support using chatbots (reducing repetitive email interactions) and suggesting products to the user based on interest.

    Similarly, social media buttons are a popular way to embed on the website that can copy the link of the page, navigate to that particular social media website and sometimes paste the URL on the post section automatically.

    Earlier, this process was done by copying the URL, then opening the social media URL and pasting this link on the post section or chat section to your friends manually, etc.

    These are, however, just small, simple examples of one type of technology used today. The main goal of exploring this topic is to understand the concept of minimal interaction and maximum expression from our application or website.

    If the user can navigate in minimum steps and interact only when it is highly required, it is harder to keep the application out of mind.

    Data Consistency on multiple platforms

    According to a survey conducted by Pew Research in 2015 for people owning a smartphone, a computer, a tablet, or a combination of these, a whopping 36% of Americans own all three devices. This number jumped to 57% in 2017, marking these cases true, especially when the user is at home.

    These statistics raise a minor issue for us as an organization. If the user is operating on multiple devices regularly, they will expect their data to be consistent across all devices.

    If we consider an eCommerce website for this, we know that users do not always purchase products instantly. Sometimes they add it to the cart and then continue shopping. Sometimes they make a wish list and buy it later in the future.

    What if a user adds an item to the cart on a mobile device but, when proceeding to purchase on the laptop, finds out that the cart is empty? Such types of data inconsistencies spoil the digital experience of the user.

    An important task of this magnitude needs rigorous testing and a vast collection of mobile devices to test upon. The major problem the testers face is procuring devices and executing the same tests on multiple devices multiple times.

    On top of it, integrating third-party applications also becomes a headache since each of those applications needs to be installed with the correct binary on the operating system.

    The best solution to deal with such issues and create a seamless digital experience for web and mobile is to rent out these devices from online digital experience testing platforms such as LambdaTest.

    These cloud-service providers do all the heavy job for you, and as a tester, all we need to do is sign up for free, select the target device, and start testing right away. LambdaTest lets you perform manual and automation testing of web and mobile apps across 3000+ real browsers, devices, and OS combinations.

    You can also test web and mobile applications in real-world scenarios using its real device cloud.

    The procurement of devices, maintenance, and integration with third-party applications is done by these providers themselves. For instance, LambdaTest can provide integration to JIRA directly from the platform. This way, when you are using the platform and encounter any bugs in the process, they can be directly uploaded to JIRA from the platform.

    These types of testing techniques ensure that the digital experience will remain consistent across various devices. It also gives confidence to the testers and organization around promoting their application on these important pillars of seamless experiences.

    Optimizing everything for mobile

    The growth of mobile devices and their usage have all seen a steep rise in the last decade. In 2015, only 31% of the world’s internet traffic came from mobile devices. Today, it is a little shy of 60%.

    This means for an organization, mobile devices are more important than other devices, such as laptops. Hence, the development and testing should be shaped according to the mobile devices to create a seamless digital experience for the web and mobile.

    Achieving this is not that hard. Currently, we work on mobile-first design techniques that allow us to develop the application first for mobile and then expand it to other devices. This way, we ensure that even if we spill on the desktops, there are no mishaps on a mobile device, and we can cover most of the audience.

    Test everything

    Finally, there is no assurance of a seamless digital experience for web and mobile until we deliberately try to break things apart. This is what testing the application means in layman’s terms.

    Application testing has evolved and optimized in various ways that can today uncover even minor bugs that were hard to point out manually earlier. From UI change detection to self-healing technologies, artificial intelligence has served the user and testers well. Taking advantage of it is one thing we need to do right to have a smooth release.

    A few of the testing paradigms include UI testing, usability testing, exploratory testing, compatibility testing (preferably through cross-browser testing tools), API testing, geo-location testing, performance testing, security testing, etc.

    Perform web and mobile app testing on a real device cloud. Sign up on LambdaTest for FREE.

    Summary

    Technologies are evolving every day, and with their evolution, the user’s experience takes different shapes from time to time. What is “trendy” today will become an “old design” or “obsolete method” in a few years (sometimes weeks depending on the type of technology). For developers and testers, it becomes one field that needs constant attention and adoption towards it.

    To provide a seamless digital experience for web and mobile, we need to focus on just five areas discussed in this post. Firstly, we should always develop in accordance with the latest trends. If things have changed, consider that they have changed for good. Users love their UX and, most of the time, are quite sensitive about it. Second, keep user interaction as minimal as possible. If users see the work getting done with the minimum input required, they will remember the applications.

    Third, if your application is available for multiple platforms, data should be consistent on all of them. If someone uploads a file and then continues on a different device, the file should be visible (in the uploaded state).

    Fourth, work on the mobile-first and then grow outward towards large-screen devices. Since mobile users are much more in number, it will make the app perfect for the majority of the audience. Finally, test everything in every way possible to determine the smallest of bugs and let the user experience the application as intended. All these steps make the application seamless and may bear fruitful results if followed.

    Resource : https://www.bleepingcomputer.com/news/security/how-to-create-seamless-digital-experiences-for-web-and-mobile/

    2May, 2023
    Cloud Computing’s Impact on the Evolution of Data Engineering ?

    Cloud technology has been a game-changer for data engineering and AI in recent years, bringing unprecedented scalability, cost-effectiveness, and flexibility. Cloud platforms like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) have become the go-to option for businesses, large and small alike, who are looking to leverage the power of data and AI without the need for in-house infrastructure. In this article, we will explore how advancements in cloud technology have helped data engineering and AI.

    What is Date Engineering?

    Data engineering is the process of designing, building and managing the data architecture, infrastructure, and pipelines required to make data accessible, reliable, and usable for downstream applications such as business intelligence, analytics, and machine learning. This involves tasks such as data ingestion, data transformation, data storage, data integration, data processing, and data quality assurance. The goal of data engineering is to enable organizations to derive insights and value from their data by providing a solid foundation for data-driven decision-making.

    Cloud Technology Advancements and Data Engineering:

    Cloud technology has made data engineering more accessible, scalable, and cost-effective. Organizations can now use cloud-based data warehousings solutions such as Amazon Redshift, Snowflake, or Google BigQuery to store and process massive amounts of data. Cloud technology has also made it easier to create data pipelines using serverless technologies like AWS Lambda, Google Cloud Functions, and Azure Functions. These serverless technologies allow organizations to run their code without the need for servers, which can significantly reduce costs and improve scalability.

    Cloud Technology Advancements and AI:

    Cloud technology has played a critical role in the rise of AI, making it more accessible to organizations of all sizes. Cloud platforms like AWS, Azure, and GCP offer AI services such as natural language processing, speech recognition, and computer vision that can be integrated into applications with ease. Additionally, these cloud platforms offer pre-trained models that can be used to build custom AI models, making it easier and faster to develop AI solutions. Cloud technology has also made it easier to train and deploy AI models at scale, with cloud-based AI platforms like Google’s TensorFlow or Microsoft’s Azure Machine Learning.

    Benefits of Cloud Technology for Data Engineering and AI:

    • Scalability – Cloud technology enables organizations to scale data processing and AI capabilities up or down depending on the demand, making it more cost-effective.
    • Cost-effectiveness – Cloud technology eliminates the need for costly infrastructure investments, allowing organizations to pay only for what they use.
    • Flexibility – Cloud technology provides organizations with the ability to access their data and AI services from anywhere, anytime, and on any device.
    • Improved Collaboration – Cloud technology enables teams to collaborate more efficiently, sharing data and models in real time.
    • Security – Cloud technology providers offer high-level security measures, including encryption and access controls, to keep data and AI models secure.

    Conclusion: Cloud technology has revolutionized the way organizations approach data engineering and AI, making it more accessible, scalable, and cost-effective. With cloud platforms like AWS, Azure, and GCP, organizations can leverage the power of data and AI without the need for expensive in-house infrastructure. Advancements in cloud technology have made it easier than ever to store, process, and analyze massive amounts of data and build custom AI models. While cloud technology offers many benefits, organizations must also consider the security implications and implement best practices to protect their data and AI models. Overall, cloud technology will continue to play a vital role in the growth and development of data engineering and AI in the years to come.

    Resource : https://timesofindia.indiatimes.com/readersblog/thethinkingcap/healthy-alternatives-for-a-longer-lifeline-53268/

    11Apr, 2023
    Noname Security releases API security updates

    API security vendor Noname Security today announced a new release of its platform, with a number of upgrades designed to enhance visibility into a user’s API environment and protect against the growing number of API-based threats.

    The growth in the number of those threats has been fueled by the increasing centrality of APIs to modern enterprise computing, Noname said in a press release. The company cited a recent report from IBM as saying that as many as two thirds of all incidents analyzed by IBM’s X-Force security team involved unsecured APIs.

    Noname’s latest updates cover a wide range of new capabilities, including customized discovery, Kubernetes features, simplified onboarding and more. The idea, according to the company, is to improve the solution’s coverage and allow it to work more quickly to discover potential vulnerabilities.

    “APIs are the connective tissue for the digital world,” said co-founder and CTO Shay Levi, in a statement.

    Visibility and discovery key to API security

    The updates, as a whole, are well-designed to target the most important parts of the broader API security issue, according to Forrester principal analyst Sandy Carielli. Visibility and discovery, for instance, are still a major challenge to many organizations. “Lots of companies don’t have a sense of what APIs are in their environments or what data is being used,” she said. “Any tooling improvements that add context to the discovery process, which this announcement talks about, I think will be good news for the organizations struggling to understand what they have.”

    Part of the problem that improved visibility attempts to solve is the presence of zombie APIs – which are APIs that have been depreciated or forgotten and aren’t in active use, but are still present on a company’s systems – and rogue APIs, which could be used to provide back doors into important subsystems.

    Testing APIs for vulnerabilities

    Testing, according to Carielli, is the other part of the API security landscape that is effectively addressed by Noname’s latest updates. Testing APIs for vulnerabilities can be time consuming based on the fact that they’re frequently not integrated in to development pipelines – as well as the aforementioned fact that there are increasingly large numbers of them present on the average company’s systems.

    “What jumps out to me about [Noname’s announcement] is the idea of leaving no API untested,” she said. “They’re looking not just at the tech but at the business logic aspects of APIs.”

    The new features are available now, and no pricing changes were announced.

    Resource : https://www.csoonline.com/article/3692248/noname-security-releases-api-security-updates.html

    10Apr, 2023
    Researchers disclose critical sandbox escape bug in vm2 sandbox library

    The development team behind the vm2 JavaScript sandbox library addressed a critical Remote Code Execution vulnerability.

    The developers behind the vm2 JavaScript sandbox module have addressed a critical vulnerability, tracked as CVE-2023-29017 (CVSS score 9.8), that could be exploited to execute arbitrary shellcode.

    vm2 is a sandbox that can run untrusted code in an isolated context on Node.js servers, it has approximately four million weekly downloads and its library is part of 722 packages.

    The flaw was reported by the security researcher Seongil Wi from South Korean security firm KAIST WSP Lab.

    The vulnerability affects all versions, including and prior to 3.9.14, it was addressed with the release of version 3.9.15.

    “vm2 was not properly handling host objects passed to Error.prepareStackTrace in case of unhandled async errors.” reads the advisory published by vm2. “A threat actor can bypass the sandbox protections to gain remote code execution rights on the host running the sandbox.”

    Wi also published two proof-of-concept (PoC) exploits for this vulnerability that can be used to escape the sandbox to create an empty file named “flag” on the host.

    In October 2022, VM2 maintainers addressed another critical sandbox escape vulnerability tracked as CVE-2022-36067.

    Please vote for Security Affairs (https://securityaffairs.com/) as the best European Cybersecurity Blogger Awards 2022 – VOTE FOR YOUR WINNERS
    Vote for me in the sections:

    • The Teacher – Most Educational Blog
    • The Entertainer – Most Entertaining Blog
    • The Tech Whizz – Best Technical Blog
    • Best Social Media Account to Follow (@securityaffairs)

    Resource : https://securityaffairs.com/144582/hacking/vm2-rce-sandbox-escape.html