This blog is all about Cyber Security and IT

Thursday, April 11, 2024

Understanding Cyber Security Threat Modeling: A Comprehensive Guide


In today's interconnected world, cyber security is more critical than ever. Organizations and individuals alike face a multitude of threats from malicious actors seeking to exploit vulnerabilities in systems and networks. Threat modeling is a structured approach to identifying and mitigating these risks effectively. Let's delve into what threat modeling is, its importance, and explore three real-world examples to better understand this essential concept.


What is Threat Modeling?

Threat modeling is a systematic process of identifying potential threats, vulnerabilities, and impacts to better understand and mitigate risks within a system or application. By conducting threat modeling, organizations can proactively assess security risks, prioritise defenses, and make informed decisions to strengthen their overall security posture.


Steps Involved in Threat Modeling:


Threat modeling typically involves several key steps:


1. Define the System Scope: Begin by clearly defining the system or application that you are assessing. Identify the boundaries, components, data flows, and interactions involved.


2. Identify Assets: Determine the critical assets within the system. This could include sensitive data, intellectual property, infrastructure components, or user accounts.


3. Identify Threats: Brainstorm potential threats and vulnerabilities that could impact the system. Consider both technical and non-technical threats such as malware, insider threats, data breaches, or physical attacks.


4. Assess Risks: Evaluate the likelihood and potential impact of each identified threat. Use risk assessment techniques to prioritize risks based on their severity.


5. Mitigation Strategies: Develop and implement appropriate countermeasures to address the identified risks. This could involve applying security controls, implementing secure coding practices, or improving security awareness among users.


6. Validate and Update: Regularly validate the threat model against evolving threats and update it as necessary to reflect changes in the system or its environment.


Real-World Examples of Threat Modeling:


Let's explore three practical examples of threat modeling:


1. E-commerce Platform:


   Scope: An online retail platform that handles customer transactions and sensitive financial information.


   Threats: Payment fraud, SQL injection attacks, account takeover, DDoS attacks.


   Mitigation Strategies: Use of secure payment gateways, input validation, multi-factor authentication, and regular security testing.


2. Healthcare System:


   Scope: A hospital's electronic health records (EHR) system storing patient data.


   Threats: Unauthorized access to patient records, ransomware attacks, insider threats.


   Mitigation Strategies:  Role-based access controls, encryption of sensitive data, employee training on security best practices.


3. IoT Device:


   Scope: A smart home device connected to the internet.


   Threats: Remote exploitation, privacy breaches, unauthorised access to home networks.


   Mitigation Strategies:  Firmware updates, strong authentication mechanisms, network segmentation.


Conclusion:


Threat modeling is a proactive approach to cybersecurity that enables organisations to anticipate and mitigate potential threats before they can be exploited. By following a structured threat modeling process, businesses and individuals can significantly enhance their security defenses and safeguard against a wide range of cyber threats. Stay vigilant, assess risks regularly, and remember that effective threat modeling is an ongoing commitment to protecting valuable assets and data in today's digital landscape.

Wednesday, May 10, 2023

How to check mongo db public availability without authentication?


MongoDB is a popular NoSQL database used by many organizations around the world. It is known for its flexibility and scalability, making it a popular choice for modern applications. However, like any database, it is important to ensure that it is secured properly. One of the key aspects of securing a MongoDB database is to ensure that it is not publicly accessible without proper authentication.


In this article, we will discuss how to check if a MongoDB database is publicly available without authentication. There are several tools and techniques available that can help you determine the public accessibility of your MongoDB database.


Method 1: Using Nmap


Nmap is a popular network scanner that can be used to scan for open ports and services on a network. By default, MongoDB listens on port 27017. Therefore, you can use Nmap to scan for this port to determine if a MongoDB database is running on the network.


To scan for port 27017 using Nmap, you can use the following command:


```

nmap -p 27017 <mongodb_server_ip>

```


If the scan returns that port 27017 is open, it means that a MongoDB database is running on the server and is publicly accessible without authentication.


Method 2: Using the MongoDB Shell


The MongoDB shell is a command-line interface that can be used to interact with a MongoDB database. If you have access to the MongoDB shell, you can use it to check if the database is publicly accessible.


To connect to the MongoDB shell, use the following command:


```

mongo --host <mongodb_server_ip> --port 27017

```


If the connection is successful, you will see the MongoDB shell prompt. You can then use the following command to check if authentication is required to access the database:


```

db.runCommand({ connectionStatus: 1 })

```


If authentication is not required, you will see the following output:


```

"ok" : 1,

"user" : "",

"authInfo" : {

  "authenticatedUsers" : [ ]

},

"ismaster" : true,

"...


If authentication is required, you will see output similar to the following:


```

"ok" : 0,

"errmsg" : "not authorized on admin to execute command { connectionStatus: 1.0, $db: \"admin\" }",

"code" : 13,

"codeName" : "Unauthorized",

"...

```


Method 3: Using the MongoDB Compass


The MongoDB Compass is a graphical user interface that can be used to manage MongoDB databases. If you have access to the MongoDB Compass, you can use it to check if the database is publicly accessible.


To connect to the MongoDB Compass, launch the application and enter the connection details. If the connection is successful, you will see the databases that are available on the server.


If the database does not require authentication, you will be able to access it without entering any credentials. You will also be able to see all the collections and documents in the database.


Conclusion


Securing a MongoDB database is an essential aspect of any modern application. It is important to ensure that the database is not publicly accessible without proper authentication. By using the methods outlined in this article, you can determine if your MongoDB database is publicly accessible without authentication. If it is, you should take steps to secure it immediately to avoid any potential security breaches.

Tuesday, May 9, 2023

How to secure Elastic Search Database?


Elastic Search is a distributed and scalable search engine that is designed to store and search large volumes of data rapidly and efficiently. While Elastic Search comes equipped with several security features, such as role-based access control, encryption, and authentication, it is still vulnerable to various types of attacks if not configured correctly. In this article, we will discuss how to secure an Elastic Search database.


1. Enable SSL/TLS Encryption


One of the most important steps to secure your Elastic Search database is to enable SSL/TLS encryption. SSL/TLS encryption ensures that all data transmitted between clients and Elastic Search nodes is encrypted, making it difficult for attackers to intercept and read the data. You can enable SSL/TLS encryption by generating a self-signed certificate or purchasing one from a trusted certificate authority.


2. Configure Access Control


Elastic Search provides various security features to control access to data stored in the database. These features include role-based access control, authentication, and authorization. You can create different roles with different privileges and assign them to users based on their responsibilities. You can also configure authentication mechanisms such as LDAP, Active Directory, or SAML to authenticate users.


3. Disable Unnecessary Plugins


Elastic Search offers several plugins that enhance the functionality of the database. However, not all plugins are secure, and some may even introduce vulnerabilities to your database. Therefore, it is essential to disable any plugins that are not necessary for your use case.


In conclusion, Elastic Search is a powerful tool for managing large volumes of data, but it is important to take steps to secure your Elastic Search database. By enabling SSL/TLS encryption, configuring access control, and disabling unnecessary plugins, you can reduce the risk of attacks on your database and ensure that your data is kept safe and secure. 

How we detect misconfigured Google Firebase Database?


Firebase is a cloud-based database platform developed by Google, designed to help developers build web and mobile applications with ease. However, misconfigured Google Firebase databases have been a significant security concern in recent times. Firebase databases are often misconfigured due to lack of knowledge or negligence, leaving them open to attack by hackers.


A misconfigured Firebase database refers to a database that is not secured correctly, allowing unauthorised access to sensitive information. Hackers can use these vulnerabilities to steal data or compromise user privacy. Firebase databases are generally easy to use and set up, making them popular among developers, but this can lead to misconfigurations.


One common mistake is not setting proper permissions on the database. Firebase databases have rules that dictate who can read, write or modify data. If these rules are not correctly set up, attackers can gain access to data they are not authorised to view or modify.


Another common mistake is not properly securing API keys. Firebase databases use API keys to access and modify data. If these keys are not properly secured, attackers can use them to gain access to sensitive information or to modify data.

A misconfigured Firebase database can result in data breaches, stolen data, or compromised user privacy. Recently, a security researcher discovered over 300,000 open Firebase databases that contained sensitive data such as passwords, email addresses, and personal information. Such a security lapse could result in identity theft or financial fraud.


The best way to prevent misconfigured Firebase databases is to follow proper security practices. This includes properly setting permissions and securing API keys. It is also essential to regularly monitor databases and perform security audits to ensure that they are secure. 


In conclusion, misconfigured Google Firebase databases can lead to significant security risks for developers and users alike. It is crucial to properly secure and monitor these databases to prevent data breaches and other security incidents. By following proper security practices and regularly auditing databases, developers can ensure that their applications are secure and protect user privacy.

How to prevent your Google Firebase Database from Hacking?


Firebase is a widely-used mobile and web application development platform that provides a cloud-based backend infrastructure. Its features include real-time database, authentication, storage, and hosting, among others. As with any cloud-based platform, Firebase is vulnerable to hacking attempts that can lead to security breaches and data theft. In this article, we will discuss some essential tips to prevent hacking of Google Firebase database.


1. Secure Your Firebase Database with Authentication

Firebase provides authentication features that help secure your database. With Firebase authentication, you can limit access to your database and prevent unauthorised entry. You can authenticate users using email and password, phone numbers, or social media accounts. Implementing role-based access control (RBAC) enables you to assign specific roles to users and restrict their access to specific data and functions.


2. Use Firebase Security Rules

Firebase security rules enable you to specify who can access your data and how they can interact with it. You can set up rules based on user authentication, data validation, user attributes, and other conditions. The Firebase security rules are written in a simple language, making it easy to understand and use. You can prevent unauthorised access, data tampering, and other security threats by implementing these security rules.


3. Implement SSL/TLS Encryption

SSL/TLS encryption is a security protocol that encrypts data transmitted over the internet. Implementing SSL/TLS encryption ensures that the data is transmitted securely and cannot be intercepted by third parties. It is essential to configure your application to use SSL/TLS encryption to secure the connection between your application and the Firebase database. Firebase provides SSL/TLS encryption by default.


4. Monitor Your Firebase Database

Regularly monitoring your Firebase database is crucial in preventing hacking attempts. You should monitor your database for suspicious activity, such as unusual logins, data downloads, or data modifications. The Firebase monitoring dashboard provides a way to monitor your database usage and performance. You can also set up alerts to notify you of any suspicious activity.


5. Keep Your Firebase Database Up-to-Date

Firebase regularly releases updates and patches to fix security vulnerabilities and bugs. Keeping your Firebase database up-to-date with the latest version ensures that it is secure. You should also keep your application's dependencies and libraries up-to-date to prevent security vulnerabilities in third-party code.


In conclusion, securing your Firebase database is essential to prevent hacking attempts and data breaches. By implementing authentication, security rules, SSL/TLS encryption, monitoring, and keeping your database up-to-date, you can ensure that your Firebase database is secure. Remember that security is an ongoing process, and you should continuously monitor and improve your security measures to stay ahead of security threats.

Thursday, April 20, 2023

Carriage Return and Line Feed (CRLF) Injection


Carriage Return and Line Feed (CRLF) Injection is a type of injection attack that targets web applications. This type of attack is also known as HTTP Response Splitting.


The attack works by injecting CRLF characters into user input fields on a website. These characters are used to separate HTTP headers from the body of a response. By injecting these characters, an attacker can split the HTTP response into two parts, allowing them to inject their own HTTP headers and potentially execute malicious code.


For example, an attacker could inject CRLF characters into the "Referer" header of an HTTP request. This could allow them to inject their own HTTP headers and execute code on the server or the client's browser.


To prevent CRLF Injection attacks, developers should validate all user input and sanitize it before using it in HTTP responses. It's also important to encode any user input that is included in HTTP headers or response bodies.


In addition, web application firewalls (WAFs) can help protect against CRLF Injection attacks by filtering out requests that contain suspicious characters. However, these should not be relied upon as the sole protection against CRLF Injection attacks.


In conclusion, CRLF Injection attacks can be dangerous and should be taken seriously by web developers. By following best practices for input validation and encoding, developers can help prevent these types of attacks and keep their web applications secure. is a type of injection attack that targets web applications. This type of attack is also known as HTTP Response Splitting.


The attack works by injecting CRLF characters into user input fields on a website. These characters are used to separate HTTP headers from the body of a response. By injecting these characters, an attacker can split the HTTP response into two parts, allowing them to inject their own HTTP headers and potentially execute malicious code.


For example, an attacker could inject CRLF characters into the "Referer" header of an HTTP request. This could allow them to inject their own HTTP headers and execute code on the server or the client's browser.


To prevent CRLF Injection attacks, developers should validate all user input and sanitize it before using it in HTTP responses. It's also important to encode any user input that is included in HTTP headers or response bodies.


In addition, web application firewalls (WAFs) can help protect against CRLF Injection attacks by filtering out requests that contain suspicious characters. However, these should not be relied upon as the sole protection against CRLF Injection attacks.


In conclusion, CRLF Injection attacks can be dangerous and should be taken seriously by web developers. By following best practices for input validation and encoding, developers can help prevent these types of attacks and keep their web applications secure.

For Detailed Explanation Refer to :

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CRLF%20Injection

Threat Hunting with Splunk


 Username guessing brute force attack


index="your index name here" sourcetype=windows EventCode=4625 OR EventCode=4624
| bin _time span=5m as minute
| rex "Security ID:\s*\w*\s*\w*\s*Account Name:\s*(?<username>.*)\s*Account Domain:"
| stats count(Keywords) as Attempts,
count(eval(match(Keywords,"Audit Failure"))) as Failed,
count(eval(match(Keywords,"Audit Success"))) as Success by minute username
| where Failed>=4
| stats dc(username) as Total by minute
| where Total>5


AD Password Change Attempts

index="your index name here" source="WinEventLog:Security" "EventCode=4723" src_user!="*$" src_user!="_svc_*"
| eval daynumber=strftime(_time,"%Y-%m-%d")
| chart count by daynumber, status
| eval daynumber = mvindex(split(daynumber,"-"),2)


Find Passwords Entered As Usernames

index="your index name here" source=WinEventLog:Security TaskCategory=Logon Keywords="Audit Failure"
| eval password=if(match(User_Name, "^(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.*[\W])(?=.{10,})"), "Yes", "No")
| stats count by password User_Name
| search password=Yes


Failed Attempt to Login To A Disabled Account

index="your index name here" source="WinEventLog:security" EventCode=4625 (Sub_Status="0xc0000072" OR Sub_Status="0xC0000072") Security_ID!="NULL SID" Account_Name!="*$"
| eval Date=strftime(_time, "%Y/%m/%d")
| rex "Which\sLogon\sFailed:\s+\S+\s\S+\s+\S+\s+Account\sName:\s+(?<facct>\S+)"
| eval Date=strftime(_time, "%Y/%m/%d")
| stats count by Date, facct, host, Keywords
| rename facct as "Target Account" host as "Host" Keywords as "Status" count as "Count"



Changes to Windows User Group by Account

index="your index name here" sourcetype=WinEventLog:Security (EventCode=4728 OR EventCode=4732 OR EventCode=4746 OR EventCode=4751 OR EventCode=4756 OR EventCode=4161 OR EventCode=4185)
| eval Date=strftime(_time, "%Y/%m/%d")
| rex "Member:\s+\w+\s\w+:.*\\\(?<TargetAccount>.*)"
| rex "Account\sName:\s+(?<SourceAccount>.*)"
| stats count by Date, TargetAccount, SourceAccount, Group_Name, host, Keywords
| sort - Date
| rename SourceAccount as "Administrator Account"
| rename TargetAccount as "Target Account"


Privilege Escalation Detection

index="your index name here" sourcetype="WinEventLog:Security" (EventCode=576 OR EventCode=4672 OR EventCode=577 OR EventCode=4673 OR EventCode=578 OR EventCode=4674)
| stats count by user


File Deletion Attempts

index="your index name here" sourcetype="WinEventLog:Security" EventCode=564
| eval Date=strftime(_time, "%Y/%m/%d")
| stats count by Date, Image_File_Name, Type, host
| sort - Date

Concept of CI/CD in Detail





CI stands for Continuous Integration. 

The purpose of CI is to provide developers with rapid feedback regarding the quality of their code in relation to the rest of the project. When changes are made to the git repository (or SVN or another preferred version control system), a PR (pull request) is created to merge the changes into the main branch. This triggers the CI pipeline, which compiles and builds the code (if applicable) and performs various automated tests, such as unit tests and code coverage.


The purpose of these tests is to ensure that the code integrates well with the rest of the application. If all tests pass, the code can be merged into the main branch with approval from another team member. The CI pipeline should also prepare an artifact, which can be a simple zip file or a more complex executable file or package. The artifact is then pushed to an artifactory, such as AWS S3 or Nexus, which allows for versioning.


CD ensures that the code is not only integrated well with the application but is also deployable to an environment that closely mimics production. If the application follows a microservices architecture, CD performs tests against the entire system, including end-to-end tests and User Acceptance Tests (UAT). CD pulls the artifact from the artifactory and delivers it to one or more environments. The same artifact is used in all stages of CD.


However, delivering the artifact to production must be done manually due to its criticality. Someone must select which version of the artifact can be released to production and trigger the same CD process against the live environment. CD involves working with deployment, which can range from simply uploading files through FTP or rsync to using configuration management tools like Ansible or AWS SSM. If the environment is containerized, kubectl, helm, and kustomize are used. Environments can also be created and destroyed on the fly using IaC tools like Terraform and Packer.


In more advanced scenarios, deployment to production can also be automated, known as continuous deployment. However, it requires extensive testing to guarantee code and application quality in production. QA includes functional testing, performance testing, stress testing, among others. CD should also feature the ability to roll back failed deployments, which can be achieved through blue/green deployments and feature gates.