This blog is all about Cyber Security and IT

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.





Wednesday, March 29, 2023

How to Study Cyber SOC at home in 2023


Below is the complete guide to help you study cyber SOC at home.

Lets install SIEM First:

 There are various SIEM in the market like: QRadar, Graylog, ELK, Splunk, SumoLogic etc but we will example of Q RADAR

Download >https://lnkd.in/d7ATK9ND
install >https://lnkd.in/dWe7gZ7f

All material you need:- 


If you encounter any of these issues below, I've collected the solutions.

. install WinCollect Agent another way:
https://lnkd.in/dA34UhEV |
https://lnkd.in/db_7ai_j

. send Linux logs to Qradar
https://lnkd.in/dnc6HYw9

. No Log Activity | Qradar CE 
https://lnkd.in/dTa2kFrM

. No Log Activity | Qradar Code:
https://lnkd.in/d3ZSVzx3

. Logs source problem:
https://bit.ly/3QyysPD

. Modify maximum Log size using Group Policy
https://lnkd.in/dmD7jqGK


. Rule creation, use case creation Basic in Qradar SIEM
https://lnkd.in/daWJmTu3 |
https://ibm.co/3DwndEq

✔️ Don't forget to generate an Authentication token from AS to write in WinCollect Agent when you install it

✔️ where logs and events from Windows, Linux, DB,..,etc :
 . DSM Configuration Guide: https://ibm.co/3dhP9Bl
Does it work? Great! That is a mini SOC. Document it somewhere and link it to your resume.🙏


------> Additional steps: <------

- Increase log visibility (activate PowerShell logging, Scriptblock logging, install Sysmon, etc)

- Install extra tools to get more visibility e.g.: Bluespan, DeepBlueCLI, Suricata Zeek, RITA (all are on GitHub)

- Test your setting! Be a bad guy and try to catch yourself. (WinPwn, Atomic Red Team, Caldera -> again, check out GitHub)

- If needed improve your SIEM with matching alert rules and build Dashboards. (Ideas? Look at Sigma rules -> GitHub)