Splunk Enterprise deployment servers in versions before 9.0 let clients deploy forwarder bundles to other deployment clients through the deployment server. An attacker that compromised a Universal Forwarder endpoint could use the vulnerability to execute arbitrary code on all other Universal Forwarder endpoints subscribed to the deployment server.

Read this topic to learn about the security improvements in the Splunk Enterprise and Splunk Cloud platforms and how you can further secure your deployments with these updates.

See the "Last modified" information at the end of this topic to determine if the topic has been updated since you last reviewed it.

**Introduction**

Splunk Enterprise and Splunk Cloud Platform now offer additional options that let you and Splunk operate deployments more securely.

The improvements center around the following themes:

*   The addition of Transport Layer Security (TLS) certificate host name validation and other improvements when Splunk platform instances make secure connections
    *   In particular, the Splunk daemon (splunkd), all Python modules that the Splunk platform uses, the Splunk CLI, and App Key Value Store now support TLS certificate validation
*   Improvements to universal forwarder security, including the limiting of access to the UF management port to only the local machine
*   Upgrades to Splunk deployment client and server authentication logic, including restrictions on how and with what those instance types can communicate

The table in the "Summary of changes" section of this topic provides a summary of the changes, and the following sections provide additional details.

All of these changes come in one of two operational modes. To understand the modes and how they affect your Splunk platform deployment, see Understand warning mode versus enforcement mode for security updates later in this topic.

**Summary of changes**

The following table lists a summary of the changes, the Splunk platforms on which the changes ship, the enforcement mode in which they currently operate, and links to procedures on how to configure Splunk software to enforce the changes.

Change

Description

Introduced in

Addresses

Current mode

Learn more

TLS certificate host name validation

Splunk platform instances verify the hostname in the TLS certificate they receive when they connect to other Splunk platform instances.

Splunk  
Cloud  
Platform (SCP)  
8.2.2202,  
Splunk  
Enterprise (SE)  
9.0

SVD-2022-0602, SVD-2022-0603

Warning

Learn more

Python module TLS  
connection hardening

Python modules on Splunk platform instances always validate TLS connections.

SCP 8.2.2202,  
SE 9.0

SVD-2022-0601

Warning

Learn more

TLS certificate host name  
validation using Splunk CLI

The Splunk Command Line Interface (CLI) validates TLS certificates for any connections it makes to other Splunk platform instances.

SCP 8.2.2203,  
SE 9.0

SVD-2022-0606

Warning

Learn more

Universal forwarder security

Universal forwarders always validate connections from other Splunk platform instances.

SE 9.0

SVD-2022-0605

Enforcement

Learn more

Universal forwarders now support the least-privileged user model for operations on Linux machines.

SE 9.0

\--

Warning

Learn more

Deployment client and  
server authentication logic

Communication protocols between deployment clients and servers, including handshake, subscription, and heartbeat logic, change.

SE 9.0

\--

Warning

Learn more

Deployment clients require authentication to download or execute forwarder bundles.

SE 9.0

SVD-2022-0607, SVD-2022-0608

Enforcement

Learn more

Risky search command safeguard improvements

You must assign additional capabilities to run some risky and custom search commands.

SE 9.0

SVD-2022-0604

Enforcement

Learn more

**Details of security updates**

A detailed listing of the changes follows. Follow the links in the "Summary of changes" table for details on how to activate the improvements in your environment.

**Transport Layer Security**

Splunk platform components use Transport Layer Security (TLS) to connect securely to one another and internal and external APIs. Each connection uses a TLS certificate to establish the secure connection. The certificates verify that the Splunk platform instances that make the connection are who they say they are. TLS certificates can be configured and validated for nearly all Splunk platform instance types, including indexers, indexer clusters, search heads, search head cluster nodes, deployers, forwarders, deployment servers, license servers, and App Key Value Store.

Most of these improvements center around how the Splunk platform handles TLS certificates. Prior to these updates, Splunk platform instances did not specifically verify the host name information within the TLS certificate that they received when they connected to other instances or APIs. This additional verification step must happen to ensure that the machine to which the instances connected is who it claims to be, and prevents what is known as a "machine-in-the-middle" attack. This is a cyberattack where a malicious actor can position a machine between the two Splunk platform instances on the network and intercept messages between them without either knowing that they aren't actually communicating with each other.

Before the certificate verification can work, Splunk platform instances must be configured to require that the instances that they connect to present a valid certificate prior to the connection completing. This certificate requirement option is different from the host name verification option, and has been available for some time. Many customers already require their Splunk platform instances to present certificates to ensure increased security in their Splunk platform deployments.

Beginning with the 8.2.2202 release of Splunk Cloud Platform and version 9.0 of Splunk Enterprise, you can configure Splunk platform instances to perform host name validation upon connecting to other Splunk platform instances and receiving TLS certificates.

Many of the security changes are disabled initially to prevent problems with downtime in your environment. This is the case with TLS certificate validation. On Splunk Enterprise deployments, and on data collection and forwarding tiers for Splunk Cloud Platform deployments that you manage, as the Splunk administrator, you can enable the feature after you confirm that the TLS certificates in your deployment have the proper configuration. In later versions of both Splunk Enterprise and Splunk Cloud Platform, Splunk will enable the enforcement of certificate validation.

TLS certificate host name validation does not work with the default certificates that come with Splunk Enterprise. You must either generate or obtain certificates from a third party and install them in all of the instances of your Splunk platform deployment. You must then configure the instances to require that they get a valid TLS certificate from other instances upon connection, and that those certificates pass the host name validation check.

Follow the documentation links from this page to the appropriate procedures to perform enablement of TLS certificate validation. You can work with Splunk Support of Professional Services for the best course of action depending on the size of your deployment.

**Deployment client and server authentication logic**

The authentication, subscription, and heartbeat logic for deployment clients and servers has changed. No communication between instances happens without TLS certificate validation. The way that deployment clients subscribe to deployment server channels has also changed, and deployment clients ignore certain types of messages that do not specifically come from deployment servers.

Deployment client and server protocol updates begin in warning mode. Splunk does not expect this change to affect your deployment negatively.

**Universal forwarder security**

Universal forwarders now have improved security. Beginning with Splunk Enterprise version 9.0, forwarders now require a configuration change to accept inbound connections to their management port from other machines. Additionally, when universal forwarders act as deployment clients, they receive the same deployment-client-to-deployment-server authentication, subscription, and heartbeat logic changes that other deployment clients receive.

Universal forwarder security updates, with the exception of changes to deployment server logic, begin in enforcement mode. Splunk does not expect this change to affect your deployment negatively.

**Risky search command safeguard improvements**

Splunk has added some capabilities that you must assign to users who need to run the dump search command and any custom search commands. Dashboards that currently use these commands might break if the user that created the dashboards does not hold a role with these capabilities.

**What is a valid TLS certificate?**

A valid certificate is one that satisfies all of the following criteria:

*   It must not be one of the default certificates that come with the Splunk platform installation packages. Validation doesn't work with the default certificates.
*   It must be a regular text file that is in privacy enhanced mail (PEM) format. Validation doesn't work with certificates that are in other formats.
*   It must be a full certificate chain. Validation doesn't work with only a leaf certificate.
*   It must contain any intermediate certificates, along with the root and server certificate, where applicable.
*   It must be valid within its date range. Expired certificates and certificates whose validity has not yet come into force don't work.
*   It must use a valid Common Name (CN) or Subject Alternate Name (SAN) X.509 certificate standard field.
    *   Either of those fields must contain a value that matches the host name of the machine that serves the certificate to the connecting client.

If the certificate doesn't meet all of these criteria, then validation, and the connection, fails. Because individual Splunk platform instances must make many network connections to share data, search jobs, artifacts, knowledge bundles, and other Splunk-related information, failed connections can cause problems with Splunk deployments.

**Understand warning mode versus enforcement mode for security updates**

The security updates that this topic discusses come in two operation modes. These modes control how the Splunk platform reacts to items in your deployment that do not meet updated Splunk security best practices.

**Warning mode**

In Warning mode, Splunk platform instances log problems with configurations that do not align with updated security best practices. Enforcement of the updates does not occur in this mode. Your Splunk Cloud Platform or Splunk Enterprise deployment operates as it currently does, only generating additional logs about the out-of-specification configurations. At any time, you can review the logs to see where your deployment is out of compliance and subsequently reconfigure the instances to bring them into compliance and enable enforcement of the updates.

If you activate and use the Splunk Assist monitoring service, it can identify the instances in your deployment that are out of compliance and provide tools to help you get them into compliance. See Introduction to Splunk Assist for additional information about the service and the details it provides.

**Enforcement mode**

In Enforcement mode, Splunk platform instances enforce the new security changes. If your configuration does not meet the updated best practices for security, then connections between Splunk platform instances, processes, and APIs can fail, which can cause the deployment to experience breaking problems and downtime.

When Splunk ships versions of the Splunk platform that enable enforcement mode, problems can begin immediately after an upgrade if you have not enabled certificate requirements and TLS host name validation. Ensure that your Splunk platform instances have valid certificates, and that TLS certificate requirements and certificate host name validation are on. You cannot use the default certificates that come with Splunk platform instance installation packages - you must either generate or obtain certificates from a third party.

**When and how each mode affects your Splunk deployment**

Some of the security updates start in enforcement mode by default. Splunk does not expect security updates that initially start in enforcement mode to negatively affect Splunk Cloud Platform or Splunk Enterprise deployments. You can monitor your deployment to see whether enforcement mode affects your deployment. The "Summary of changes" table that appears earlier in this topic lists the current operating mode for each security update.

All other changes initially begin in warning mode. Changes that begin in warning mode give you time to configure your Splunk Cloud Platform or Splunk Enterprise deployment to begin enforcing the security updates. To do this, see "Configure your Splunk platform deployment to enforce security updates" later in this topic. Eventually, Splunk will update these changes to operate in enforcement mode by default.

**Steps to address the security update warnings and errors**

When you update Splunk Enterprise or Splunk updates Splunk Cloud Platform, security update warnings and errors appear in the splunkd.log file, and for App Key Value Store, the mongodb.log log file. You can review either of the files themselves for the warnings, or you can search the _internal index from Splunk Web.

The warnings and errors that you see depend on the operating mode each security update is currently in, the action that the Splunk platform instance is trying to perform, the Splunk service or command that performs the action, and the current state of your configuration. You might see errors that are similar to, but not exactly like, the ones that appear in this table.

Current state

What the logs say

What you need to do

You have the proper certificates in place and you have enabled both the requirement for TLS certificates and TLS certificate host name validation.

Nothing

Nothing

You have the proper certificates in place and have enabled the requirement for TLS certificates, but haven't yet turned on TLS certificate host name validation.

Nothing

Enable TLS certificate host name validation.

You have the proper certificates in place, but haven't yet enabled TLS certificate requirements or certificate host name validation.

An error message similar to the following, when the instance starts up, in the SSLOptions channel of the splunkd.log file:  

sslVerifyServerCert is false disabling certificate validation; must be set to "true" for increased security

Enable TLS certificate requirements and certificate host name validation.

You use the default certificates that come with the Splunk platform installation packages, and haven't yet turned on TLS certificate requirements or certificate host name validation.

An error message similar to the following, when the instance starts up, in the SSLOptions channel of the splunkd.log file:  

sslVerifyServerCert is false disabling certificate validation; must be set to "true" for increased security

Obtain and install valid certificates. Then enable TLS certificate requirements and certificate host name validation.

You use the default certificates that come with the Splunk platform installation packages, or haven't yet turned on TLS certificate requirements or certificate host name validation, and try to connect to another Splunk instance using the CLI.

An error message similar to the following:  

WARNING: Server Certificate Hostname Validation is disabled. Please see server.conf/\[sslConfig\]/cliVerifyServerName for details.
Login failed

Obtain and install valid certificates. Then enable TLS certificate requirements and certificate host name validation. Then, try the CLI command again.

You use the default certificates that come with the Splunk platform installation packages, haven't yet turned on TLS certificate requirements or certificate host name validation, and later upgrade to a release that enables certificate validation by default

For connections between Splunk platform instances, TLS connection errors similar to the following:  

2022-03-04T20:41:00.231Z E NETWORK  \[NetworkInterfaceASIO-Replication-0\] SSL peer certificate validation failed: self signed certificate in certificate chain
2022-03-04T20:41:00.231Z W ASIO     \[NetworkInterfaceASIO-Replication-0\] Failed to validate peer certificate during SSL handshake: SSLHandshakeFailed: SSL peer certificate validation failed: self signed certificate in certificate chain
2022-03-04T20:41:00.231Z I ASIO     \[NetworkInterfaceASIO-Replication-0\] Failed to connect to 10.202.5.121:8191 - SSLHandshakeFailed: SSLHandshakeFailed
2022-03-04T20:41:00.231Z I ASIO     \[NetworkInterfaceASIO-Replication-0\] Dropping all pooled connections to 10.202.5.121:8191 due to failed operation on a connection

For connections from the CLI, errors similar to the following:  

ERROR: certificate validation: self signed certificate in certificate chain
ERROR: certificate validation: self signed certificate in certificate chain
Couldn't complete HTTP request: error:14090086:SSL routines:ssl3\_get\_server\_certificate:certificate verify failed

**Downtime risk.** Splunk platform instances won't be able to connect with each other.

Obtain and install valid certificates. Then enable TLS certificate requirements and certificate host name validation. Then, if using the CLI, try the CLI command again.

**Configure your Splunk platform deployment to enforce security updates**

When you upgrade to Splunk Enterprise version 9.0, or Splunk upgrades your Splunk Cloud Platform instance to version 8.2.2202 and higher, the changes that this topic describes are available for you to enable. Splunk has already enabled some of the changes.

To configure the Splunk platform deployment to use enforcement mode for all changes, do the following:

1.  Ensure you have valid certificates. If you don't, get or create them. See the following topics for instructions:
    *   To create and sign your own certificates, see How to self-sign certificates.
    *   To get certificates from a third party, see How to obtain certificates signed by a third-party for inter-Splunk communication.
2.  Install the certificates on all instances in your Splunk platform deployment, if you have not already.
3.  Follow the "Learn More" links in the "Summary of changes" table to procedures that describe how to enable certificate validation for each update.

**For further information**

See the following topics for more information:

*   For general information on using TLS to secure your Splunk platform deployments, see About securing the Splunk platform with TLS.
*   For procedures on how to enable TLS certificate host name validation, see Enable TLS certificate host name validation.

CVE-2022-32158: Security updates - Splunk Documentation

By Waqas
Apart from personal and financial records, the data also included plain-text login credentials including usernames and passwords of…
This is a post from HackRead.com Read the original post: Scoop: Uganda Security Exchange Caught Leaking 32GB of Sensitive Data

****Apart from personal and financial records, the data also included plain-text login credentials including usernames and passwords of customers and businesses using the Easy Portal of the Uganda Security Exchange.****

The Uganda Securities Exchange (USE) aka principal stock exchange in Uganda has been caught leaking highly sensitive financial and sensitive data of its customers and business entities across the globe.

This was revealed to Hackread.com by Anurag Sen, a prominent IT security researcher who has been known for identifying exposed servers and alerting relevant authorities before it’s too late. Anurag is the same researcher who discovered Australian trading giant ACY Securities to be exposing 60GB worth of data earlier this month.

**What Happened**

It all started with Anurag scanning for misconfigured databases on Shodan and noted a server exposing more than 32GB worth of data to public access. According to Anurag, the server belonged to the Uganda Security Exchange’s Easy Portal. For your information, Easy Portal is an online self-service portal that lets users and trading entities view stock performance, view statements, and monitor their account balance.

> “There are other ports running on the server which opened the link to the bank of Baroda – which is Indian based company operating in Uganda. Also, it is registered under the Uganda security exchange.”
> 
> Anurag told Hackread.com

**What Data was Leaked**

Upon further digging into the humongous dataset Anurag concluded that the exposed records were of sensitive nature. The worse part of the data leak is the fact that the server was left exposed without any security authentication.

This means anyone with a slight bit of knowledge about finding unsecured databases on Shodan and other such platforms would have complete access to USE’s data including the following:

*   Full Name
*   Usernames
*   Full Address
*   Date of Birth
*   Access tokens
*   Phone Number
*   Email Address
*   Plaintext passwords
*   ID number of Users
*   Bank details including ID, and account number
*   Details on Foreign citizens and companies including citizens based in Uganda

The screenshot below shows the type of data exposed by the USE:

Image provided to Hackread.com by the IT security researcher Anurag Sen

**No Response from Uganda CERT or USE**

Although exposing sensitive data of unsuspecting users and businesses to cybercriminals is itself a blunder, not responding to researchers and not caring about the mess up is simply irresponsible.

Anurag and Hackread.com contacted Uganda Securities Exchange, Uganda CERT (Computer emergency response team), and several other government institutions via Twitter, phone, and email however none of the authorities ever responded.

Amid this, the server remained exposed for days.

**Server Secured**

On June 12th, 2022, the 32GB worth of data was reduced to MBs. It could be that authorities wanted to keep the incident under wraps to avoid criticism from local media and entities affected by the breach. Nevertheless, at the time of publishing this article, the exposed server was secured and its IP addresses were no longer accessible to the public.

**Impact on the company and clients**

It is yet unclear whether a third party accessed the database with malicious intent such as ransomware gangs or threat actors. But in case it did, it would be devastating for the USE, its customers, and its clients including local and foreign businesses.

Furthermore, considering the extent and nature of exposed data, the incident could have far-reaching implications. Such as bad actors could download the data, sign in to Easy Portal, and carry out identity theft, phishing, or trading scams.

If you use Easy Portal, it is time to contact Uganda Securities Exchange and inquire about the incident.

**More Misconfigured Servers News**

1.  Misconfigured baby monitors exposing video stream online
2.  Anonymous hacked 90% of Russian misconfigured databases
3.  Misconfigured AWS bucket exposed 421GB of Artwork Archive data
4.  350 million email addresses exposed on misconfigured AWS S3 bucket
5.  Exposed ElasticSearch Servers Exposed 579GB of Users’ Website Activity

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Scoop: Uganda Security Exchange Caught Leaking 32GB of Sensitive Data

Plus: Russia rattles its cyber sword, a huge Facebook phishing operation is uncovered, feds take down the SSNDOB marketplace, and more.

How do you smuggle information into the USSR right under the nose of the KGB? Create your own encryption system, of course. That’s exactly what saxophonist and music professor Merryl Goldberg did during the 1980s. This week Goldberg revealed that she used musical notation to hide the names and addresses of activists and details of meetings on a rare trip to the Soviet Union. To do so, she cooked up her own encryption system. Each musical note and marking represented letters of the alphabet and helped disguise the sensitive information. When Soviet officers inspected the documents, no suspicions were raised.

Goldberg’s story was retold at the RSA Conference in San Francisco this week, where WIRED’s Lily Newman has been digging up stories. Also coming out of RSA: a warning that as ransomware becomes less profitable, attackers may turn to business email compromise (BEC) scams to make money—BEC attacks are already highly profitable.

Also this week, dark-web marketplace AlphaBay is about to complete its journey back to the top of the online underworld. The original AlphaBay site—home to more than 350,000 product listings, ranging from drugs to cybercrime services—was purged from the dark web in July 2017 as part of a huge law enforcement operation. However, AlphaBay’s second-in-command, an actor going by the name of DeSnake, survived the law enforcement operation and relaunched the site last year. Now AlphaBay is growing quickly and is on the verge of resuming its dominant dark-web market position.

Elsewhere, Apple held its annual Worldwide Developers Conference this week and revealed iOS 16, macOS Ventura and some new MacBooks—WIRED’s Gear team has you covered on everything Apple announced at WWDC. However, there are two standout new security features worth mentioning: Apple is replacing passwords with new cryptographic passkeys, and it’s introducing a safety check feature to help people in abusive relationships. Database firm MongoDB also held its own event this week, and while it might not have been as high-profile as WWDC, MongoDB’s new Queryable Encryption tool may be a key defense against preventing data leaks.

Also this week we’ve reported on a Tesla flaw that lets anyone create their own NFC car key. New research from the ​​Mozilla Foundation has found that disinformation and hate speech are flooding TikTok ahead of Kenya’s elections, which take place at the start of August. Elon Musk reportedly gained access to Twitter’s “fire hose,” raising privacy concerns. And we dove into the shocking new evidence televised by the House January 6 committee.

But that's not all, folks. Each week we round up the big security and privacy news we didn't cover ourselves. Click the links for the full stories, and stay safe out there.

For the past two years, state-sponsored hackers working on behalf of the Chinese government have targeted scores of communications technologies, ranging from home routers to large telecom networks. That’s according to the NSA, FBI, and the Cybersecurity and Infrastructure Security Agency (CISA), which published a security advisory this week detailing the “widespread” hacking.

Since 2020, Chinese-backed actors have been exploiting publicly known software flaws in hardware and incorporating compromised devices into their own attack infrastructure. According to the US agencies, the attacks typically contained five steps. China’s hackers would use publicly available tools to scan for vulnerabilities in networks. They would then gain initial access through online services, access login details from the systems, get access to routers and copy network traffic, before finally “exfiltrating” victim data.

“Exploiting these vulnerabilities has allowed them to establish broad infrastructure networks to exploit a wide range of public- and private-sector targets,” the agencies say in their joint advisory.

Since the start of the war in Ukraine, Russia has been hacked at an unprecedented scale. Now, more than 100 days into the war, tensions around cyber activity are rising. On June 9, Russia’s Foreign Ministry said that its critical infrastructure and government bodies were being hit by cyberattacks and warned that it could lead to military confrontation with the West. “The militarization of the information space by the West, and attempts to turn it into an arena of interstate confrontation, have greatly increased the threat of a direct military clash with unpredictable consequences,” the Foreign Ministry said in a statement. From the moment Russian troops entered Ukraine, questions have been raised about the potential for escalation if people outside of Ukraine are involved in cyberattacks against Russia. Last week, the head of US Cyber Command told _Sky News_ that its military hackers have been involved in offensive operations that support Ukraine.

Phishing remains one of the most successful ways for criminals to break into people’s accounts and make money—and there’s no better example of this than a newly uncovered Facebook and Facebook Messenger phishing campaign. This week, security researchers at US firm PIXM revealed a huge network of at least 400 phishing pages that are raking in millions of views and have made its creators an estimated $59 million. The scam, which has been running since at least September 2021, directs people to false Facebook login pages where their credentials are hoovered up. What stands out, as noted by the Register, is that the phishing campaign has managed to avoid Facebook’s phishing detection methods more effectively than others.

So far in 2022, police and tech companies have been cracking down on cybercriminals with some success: Raidforums, ZLoader, and the dark-web market Hydra have all been shut down in recent months. That list got a little bit longer this week as the FBI and its international law enforcement took down a marketplace selling the personal information of around 24 million Americans, according to authorities. The SSNDOB marketplace, which was made up of four individual domains, was selling people’s names, dates of birth, and Social Security numbers. SSNDOB has existed for around a decade, and in 2013, details obtained from the organization were used in the takeover of Xbox Live accounts. It’s believed the website has made its unknown owners around $22 million since 2015.

How China Hacked US Phone Networks

MongoDB claims its new “Queryable Encryption” lets users search their databases while sensitive data stays encrypted. Oh, and its cryptography is open source.

After years of data breaches, leaks, and hacks leaving the world desperate for tools to stem the illicit flow of sensitive personal data, a key advance has appeared on the horizon.

On Tuesday, MongoDB is announcing “Queryable Encryption,” a feature that will allow database users to search their data while it remains encrypted. The tool, which is debuting in preview as part of MongoDB 6.0, attempts to bridge academic cryptography findings and real-world environments so users can adopt the feature without needing advanced theoretical expertise. Crucially, Queryable Encryption is built to work with existing databases rather than requiring users to re-architect their systems before they can take advantage of it.

Institutions from businesses to governments, health care facilities, and critical infrastructure already lean on encryption to render data unintelligible (and therefore not worth stealing) when it's traveling across networks or sitting in storage. But none of that protects data when it's actively being used for legitimate reasons—looking up a patient's medical records, say, or setting up a car rental reservation. That means an attacker—including a rogue employee—could potentially gain access to data the same way a doctor or customer service agent does. This is a nut everyone wants to crack, and the database maker MongoDB has been working on possible solutions for years. Now, the company says, it has one.

“This is exactly the kind of thing that customers are wanting. We work with the biggest banks, pension systems, treasury exchanges, payment networks, pizza chains—and everyone wants better assurances,” says Kenn White, MongoDB's security principal. “And because of some practical engineering breakthroughs, it went from an academic kind of thing to something that actually could work on big databases.”

Queryable Encryption could let a bank agent investigate your account for possible fraud on a range of dates without knowing which dates specifically flagged the system. Or it could allow a customer service rep to type the first few letters of a name and start a claims process while leaving the name encrypted and indecipherable. 

Many of these breakthroughs came from Brown University cryptographer Seny Kamara and his longtime collaborator Tarik Moataz. Several years ago, the pair cofounded a searchable encrypted database startup known as Aroki Systems along with entrepreneur John Partridge. Aroki collaborated with MongoDB on a database security feature, announced in 2019, and Kamara and Moataz continued working on a prototype of a truly searchable encrypted database. In 2021, MongoDB acquired Aroki.

The Queryable Encryption system is built with a combination of established cryptographic protocols and conceptual advances Kamara and Moataz have been working on for years in an area of cryptography known as structured encryption. The approach involves encrypting data with a specific architecture so it can be searched with special tokens specific to each query without data ever being decrypted. Other techniques such as homomorphic encryption allow users to do computations on encrypted data, like adding two columns in an encrypted spreadsheet. But structured encryption is specifically focused on organizing encrypted data so it can be found without exposing the data itself.

“What we focus on is not how to do arithmetic operations on encrypted data, but how to find information fast—like really, really fast,” says Kamara, who is currently on leave from his associate professor role at Brown.

Speed is a challenge in encrypted operations, where every extra key check and computation add complications to basic operations. But MongoDB claims that searches performed with Queryable Encryption are impressively fast and won't cause unreasonable performance losses—a claim that customers will be able to test for themselves with the new preview. MongoDB is also open-sourcing much of the Queryable Encryption system, so users and other researchers can vet its underlying cryptography.

“A lot of the work is very theoretical in nature, algorithms, crypto security definitions, but for me at the end of the day I want to see something come out of it,” Kamara says. “There is a social imperative behind the work that scientists do. Working with a company at the scale of Mongo, this will be available to a huge number of people, a huge number of work loads.”

Moataz and Kamara say the big breakthrough that allowed them to move their concept from the academic world toward the real world was emulation, which enabled them to use the properties of structured encryption with existing databases that have different architectures. Like emulating Super Nintendo games on your PC or emulating Windows on a Mac, the approach creates a liminal space in which structured encryption can run on top of traditional databases.

Still, Kamara and Moataz emphasize that it's been a challenge and a learning process to collaborate with MongoDB engineers and turn the Aroki Systems prototype into something that can actually be deployed at scale around the world.

“Seny and I have been learning a lot about the constraints of real-world deployments that academics know nothing about,” Moataz says. “Models in academia are less restrictive. So we are enjoying being exposed to that and improving our models and our designs with respect to these constraints.”

Though Tuesday's release will be the first time that the public can vet Queryable Encryption in the wild, Aroki Systems had cryptographer JP Aumasson conduct technical due diligence on the cryptographic underpinning of their prototype system. And MongoDB invited University of Chicago cryptographer and searchable encryption researcher David Cash to take an early look as well. Both told WIRED that while they haven't audited the entire system deployment, the underlying cryptography appears sound. And they both emphasize that it's exciting to see a real-world searchable encryption scheme take shape after so long.

“A lot of crypto research since the 1980s has sort of been centered on how do we do this stuff, so this is a long time coming," Cash says. “Everything in cryptography is about trade-offs, and the world is complicated, so it's important to be careful about absolute statements, but that this vision is realized in some form is very exciting. And this is not at all snake oil or security theater. They're going deep on this and thinking about the important stuff carefully.”

Aumasson says that many others have claimed to offer searchable encryption without the technical depth or capability. “There have been other products advertising encrypted search, but academics would really laugh at those,” he says. “What Mongo is doing is something that is academic-compliant, and I’m very happy to see it.”

A Long-Awaited Defense Against Data Leaks May Have Just Arrived

A Server-Side Template Injection (SSTI) was discovered in Form.io 2.0.0. This leads to Remote Code Execution during deletion of the default Email template URL.

 

**A combined form and API platform for Serverless applications**

Form.io is a revolutionary combined Form and API platform for Serverless applications. This repository serves as the core Form and API engine for https://form.io. This system allows you to build "serverless" data management applications using a simple drag-and-drop form builder interface. These forms can then easily be embedded within your Angular.js and React applications using the <formio> HTML element.

**Form.io is Hiring!**

If you like what you see, and would like to come and work for a cutting edge, Open Source core company, then please apply online @ https://form-talent.freshteam.com/jobs!

**Walkthrough video and tutorial**

For a walkthrough tutorial on how to use this Open Source platform to build a Serverless application, watch the video 0 to M.E.A.N in 30 minutes

**Form Building & Rendering Demo**

Here is a link to a demo of the Form Building and Form Rendering capability that can be hooked into this API platform.

http://codepen.io/travist/full/xVyMjo/

**Run with Docker Compose**

The fastest way to run this library locally is to use Docker.

*   Install Docker
    
*   Download and unzip this package to a local directory on your machine.
    
*   Open up your terminal and navigate to the unzipped folder of this library.
    
*   Type the following in your terminal
    
        npm install
        docker-compose up
        
    
*   Go to the following URL in your browser.
    
*   Use the following credentials to login.
    
    *   **email**: admin@example.com
    *   **password**: CHANGEME
*   To change the admin password.
    
    *   Once you login, click on the **Admin** resource
    *   Click **View Data**
    *   Click on the **admin@example.com** row
    *   Click **Edit Submission**
    *   Set the password field
    *   Click **Save Submission**
    *   Logout
*   Have fun!
    

**Manual Installation (Node + MongoDB)**

To get started you will first need the following installed on your machine.

*   Node.js - https://nodejs.org/en/
*   MongoDB - http://docs.mongodb.org/manual/installation/
    *   On Mac I recommend using Homebrew brew install mongodb-community
    *   On Windows, download and install the MSI package @ https://www.mongodb.org/downloads
*   You must then make sure you have MongoDB running by typing mongod in your terminal.

**Running with Node.js**

You can then download this repository, navigate to the folder in your Terminal, and then type the following.

This will walk you through the installation process. When it is done, you will have a running Form.io management application running at the following address in your browser.

The installation process will also ask if you would like to download an application. If selected, the application can be found at the following URL.

You can also see the contents of the application (for modification) within the app folder which exists inside of the folder where you downloaded this repository.

**Development**

To start server with auto restart capability for development simply run this command:

**Deploy to Hosted Form.io**

If you wish to deploy all of your forms and resources into the Form.io Hosted platform @ https://portal.form.io, you can do this by using the Form.io CLI command line tool.

    npm install -g formio-cli
    

Once you have this tool installed, you will need to follow these steps.

*   Create a new project within Form.io
*   Create an API Key within this project by going to the **Project Settings | Stage Settings | API Keys**
*   Next, you can execute the following command to deploy your local project into Hosted Form.io.

    formio deploy http://localhost:3001 https://{PROJECTNAME}.form.io --dst-key={APIKEY}
    

You will need to make sure you replace {PROJECTNAME} and {APIKEY} with your new Hosted Form.io project name (found in the API url), as well as the API key that was created in the second step above.

This will then ask you to log into the local Form.io server (which can be provided within the Admin resource), and then after it authenticates, it will export the project and deploy that project to the Form.io hosted form.

**License Change (March 8th, 2020)**

This library is now licensed under the OSL-v3 license, which is a copy-left OSI approved license. Please read the license @ https://opensource.org/licenses/OSL-3.0 for more information. Our goal for the change to OSLv3 from BSD is to ensure that appropriate Attribution is provided when creating proprietary products that leverage or extend this library.

**Help**

We will be updating the help guides found @ https://help.form.io as questions arise and also to help you get started with Form.io.

Thanks for using Form.io!

The Form.io Team.

**Security**

If you find and/or think you have found a Security issue, please quietly disclose it to security@form.io, and give us sufficient time to patch the issue before disclosing it publicly.

CVE-2020-28246: GitHub - formio/formio: A Form and Data Management Platform for Progressive Web Applications.

OS Command injection vulnerability in Mintzo Docker-Tester through 1.2.1 allows attackers to execute arbitrary commands via shell metacharacters in the 'ports' entry of a crafted docker-compose.yml file.

**docker-tester**

Set up a testing environment with a docker-compose file and verify its up before running tests

  

**Install**

npm i docker-tester --save-dev

*   _docker and docker-compose are required to be installed and acsecible from the terminal, you can get it here_

**Example****running tests in mocha**

const TestingEnvironment \= require('docker-tester');

const testingEnvironment \= new TestingEnvironment({

  dockerComposeFileLocation: \_\_dirname,

  dockerFileName: 'test.docker-compose.yml',

  verifications: { 

    httpServer: {  

      verificationFunction: async (service) \=> { 

      },  promiseRetryOptions: { retries: 4 } }

  } });

before(async function () {

  this.timeout(0);

  await testingEnvironment.start();

});

after(async function () {

  this.timeout(0);

  await testingEnvironment.stop();

});

describe('Simple Usage', () \=> {

  it('some tests', () \=> {

    const service \= testingEnvironment.getActiveService('example-node-server') 

  });

});

**docker-compose file**

version: '3.1'

services:

  example-node-server:

    image: node

    ports:

      \- 7000:80

    environment:

      verificationType: httpServer 

  example-mongo:

    image: mongo

    ports:

      \- 80

    environment:

      verificationType: mongodb

Full code for this and more examples available here

**Usage**

create a new TestingEnvironment instance, .start() and .stop() async function, use docker-compose up and docker-compose down

.stop() resolves when all containers have stopped.

.start() resolves when all containers are up and ready.

in the docker-compose file, services requiring verification that they are ready will be verified according to there defined verification type, found under environment -> verificationType

TestingEnvironment instance will match verifications key to verificationType in the docker-compose file.

**Documentation****TestingEnvironment() Constructor**

the testing environment can be configured by passing in an object with the fallowing properties

required parameters:

*   dockerComposeFileLocation - the folder path where the docker-compose file is found
*   dockerFileName - the docker-compose full file name

optional:

*   verifications - verifications by type that check when services are ready
    *   verificationFunction - _required_ - an async function or a function that returns a promise to verify the service, receives the service information when called
    *   promiseRetryOptions - _(optional)_ - promise retry settings, same as promise-retry
        *   retries - number of retries , _default 5_
*   disableLogs - disables logs docker-tester actions, when set to true

example options object:

new TestingEnvironment({

  dockerComposeFileLocation: \_\_dirname,

  dockerFileName: 'test.docker-compose.yml',

  verifications \= {

  verificationType: { 

    verificationFunction,

    promiseRetryOptions

  }

}

**.start({ stopIfUp, verifyUp })**

starts all services found in the docker-compose file _(docker-compose up -d)_, verifies they are ready and then resolves, rejects if there was a problem or if verify promises are rejected

optional settings:

*   stopIfUp - _(default: true)_ - runs .stop() before starting services
*   verifyUp - _(default: true)_ - runs .verifyAllServices() after starting services

example code:

const testingEnvironment \= new TestingEnvironment({

});

await testingEnvironment.start();

**.stop()**

stops all services running services _(docker-compose down)_ then resolves,rejects if there was a problem or if verify promises are rejected.

example code:

const testingEnvironment \= new TestingEnvironment({

});

await testingEnvironment.start();

await testingEnvironment.stop();

**.verifyAllServices()**

verifies all services are ready using the service verificationType then resolves,rejects if there was a problem or if verify promises are rejected.

example code:

const testingEnvironment \= new TestingEnvironment({

});

await testingEnvironment.start({ verifyUp: false });

await testingEnvironment.verifyAllServices();

**.getActiveService(serviceName)**

returns an active service configuration by specified service name in the docker-compose file.

can be used to retrieve external exposed ip, not defining an exposed ip can enable running tests in parallel.

example-service:

    environment:

      verificationType: httpServer

    ports:

      \- '3001:80' 

  example-service:

    environment:

      verificationType: httpServer

    ports:

      \- 80 

example code:

const testingEnvironment \= new TestingEnvironment({

});

await testingEnvironment.start();

await testingEnvironment.getActiveService('example-service');

{ 

  image: 'node',

  working\_dir: '/service',

  volumes: \[ '../:/service' \],

  ports: \[ { external: "7000", internal: "3000" } \],

  command: 'npm start',

  environment: { verificationType: 'httpServer' } 

}

CVE-2021-34079: docker-tester

BigBlueButton is an open source web conferencing system. Starting in version 2.2 and up to versions 2.3.18 and 2.4-rc-6, an attacker who is able to obtain the meeting identifier for a meeting on a server can find information related to an external video being shared, like the current timestamp and play/pause. The problem has been patched in versions 2.3.18 and 2.4-rc-6 by modifying the stream to send the data only for users in the meeting. There are currently no known workarounds.

This is likely the last release candidate for BigBlueButton 2.4. It includes several functional fixes and a few privacy/security improvements (see below). If only minor items are reported in the coming days we plan on releasing 2.4.0 next. We'd like to encourage community memebers to try out this release and provide their feedback on BigBlueButton-dev forum both positive or negative.

Link to installation command / instructions/ schedule / planned features : https://docs.bigbluebutton.org/2.4/new.html

Thanks to the community members who provided feedback to the earlier 2.4 releases!

We thank Nico Heitmann, Sven Hebrok, and Juraj Somorovsky from Paderborn University who examined the BigBlueButton code base and responsibly disclosed a number of privacy and security issues that were fixed in this release.

**HTML5 client:**

newly introduced:

*   feat(webcam): add a way to re-open video preview without multiple cameras #13818
*   feat: Allow BBB to run behind a proxy the avoid gUM permission queries per node #13731
*   feat: add forceRelayOnFirefox option (false by default) #13789

fixes:

*   fix: 2.4 RC3 - bug - presentation causes the client to crash #13781
*   fix: waiting room ui regression #13776
*   fix: Space bar does not switch to move tool #13798
*   fix: Banner in meeting conflicts with layout calculation #13808
*   fix: random-user modal blocks other modals #13800
*   fix: unexpected blurred effect #13822
*   fix: Safari fullscreen issues (2.4) #13834
*   fix: Cannot interrupt audio Connecting process #13821
*   fix: typing indicator names position (2.4) #13858
*   fix: Users disappearing from the polling results when they vote #13864
*   fix: Fix presentation download url #13868 Thanks @schrd
*   fix: Keep original order of poll answers in whiteboard annotation (2.4) #13874
*   fix: prevent poll response leak #13763 **improved security**
*   fix: external video info leak #13788 **improved security**
*   fix: prevent users from being able to send more than one typed poll answer #13757 **improved permissions**
*   refactor: Remove unused user data on leave #13773 **improved privacy**
*   refactor: Removes parameters usage in the group-chat-messages and authtoken-validation publishers #13802 **improved security**
*   refactor: Update Guest Lobby Title String #13777
*   refactor: Increase sidebar-content max width value #13785
*   refactor: reduce sidebar min-width - 2.4 #13787
*   refactor(random user picker): minimise sequential user pick #13831 Thanks @hiroshisuga

test:

*   test: Updates playwright tests #13806
*   fix (test): non-iterating loop in Playwright #13860 Thanks @hiroshisuga

**bbb-web**

*   fix(core): look for session/jsession cookie in checkAuthorization endpoint #13814 **improved security**
*   feat: Add new /join param excludeFromDashboard #13764
*   chore: add user infos in custom HTTP headers to checkAuthorization's OK, forward them to SFU #13827 **improved security**

**akka-apps**

*   fix: Fixes the validation of banned users #13766 **improved permissions**
*   fix: Fix Emoji Permissions in akka-apps #13817 **improved permissions**
*   fix(webcams): viewer accounting, improved perm. checks in akka-apps, \[...\] #13790 **improved permissions**
*   feat: Add new /join param excludeFromDashboard #13764
*   refactor: New Constraint Added to Join Requests #13837
*   refactor: Remove a duplicated MeteorActor condition #13829 thanks @hiroshisuga
*   refactor: Improved annotation permissions #13803 **improved permissions**
*   refactor(random user picker): minimise sequential user pick #13831 Thanks @hiroshisuga
*   refactor: Decrease time allowed for reconnection #13878

**build / configuration**

*   disable JS execution in mongodb #13810 #13819 **improved security**
*   chore: add user infos in custom HTTP headers to checkAuthorization's OK, forward them to SFU #13827 **improved security**
*   feat: Allow BBB to run behind a proxy the avoid gUM permission queries per node #13731 Thanks @schrd
*   build: bump bbb-webrtc-sfu to v2.6.4 #13877

**bbb-webrtc-sfu**

*   updated to v2.6.4

**bbb-learning-dashboard**

*   refactor: Remove button to Copy Dashboard Link #13765
*   refactor(learning dashboard): Hides anonymous poll row #13804
*   feat: Add new /join param excludeFromDashboard #13764
*   chore: update Dashboard's package-lock.json #13848

**bbb-libreoffice**

*   refactor: Libreoffice - Force correct permissions for sudoers file #13825 Thanks @test-erik

**Recording**

*   chore(recording): Update Nokogiri + Optimist #13762

**Release name**

In case an administrator does not want to update to the latest bionic-240 version, use as substitute to the -v argument in bbb-install.sh command  
----- <-- this release candidate shipped with an issue causing client crashes after user eject. Please use 2.4-rc-7 (the next release) where this was patched  
We still recommend using -v bionic-240.

**Client build: 2421**

CVE-2022-29235: Release BigBlueButton 2.4-rc-6 · bigbluebutton/bigbluebutton

The cloud instances were left open to the public Internet with no authentication, allowing attackers to wipe the data.

Cyberattackers are targeting misconfigured Elasticsearch cloud buckets exposed on the public Internet and stealing the wide-open data, then replacing it with a ransom note.

According to Secureworks Counter Threat Unit (CTU) researchers, more than 1,200 indexes have already been affected, with the attackers issuing 450 requests for Bitcoin payment in exchange for the return of the data. However, the ransom amounts are relatively low, researchers have pointed out: Taken together, all of the demands total just $280,000.

"The average ransom request was approximately $620 payable to one of two Bitcoin wallets," they noted in a Wednesday analysis. "As of this publication, both wallets are empty and do not appear to have been used to transact funds related to the ransoms."

Despite the lackluster follow-through on the part of attackers thus far, the situation highlights a serious issue: Misconfiguration of databases placed in the public cloud has reached epidemic proportions, with large numbers of enterprises mistakenly leaving storage buckets from Amazon Web Services, Google Cloud, and Microsoft Azure accessible with no authentication to read or write the data.

Often, these open instances are discovered by security researchers and locked down without incident — but system misconfigurations still drove an estimated 13% of overall malicious system breaches recorded in the recent Verizon's 2022 "Data Breach Investigations Report" (DBIR), with misconfigured cloud storage instances making up the bulk of those.

"Unsecured Elasticsearch instances are trivially easy to identify using the Shodan search engine," the CTU researchers noted. "The threat actor probably used an automated script to identify the vulnerable databases, wipe the data, and drop the ransom note."

They added, "the cost of storing data from 1,200 databases would be prohibitively expensive. It is therefore likely that the data was not backed up and that paying the ransom would not restore it."

In 2020, ESET researchers uncovered a similar attack that affected half of all exposed MongoDB instances, which were wiped and replaced with a ransom note.

12K Misconfigured Elasticsearch Buckets Ravaged by Extortionists

An access control issue in Linglong v1.0 allows attackers to access the background of the application via a crafted cookie.

一款资产巡航扫描系统。系统定位是通过masscan+nmap无限循环去发现新增资产，自动进行端口弱口令爆破/、指纹识别、XrayPoc扫描。主要功能包括: 资产探测、端口爆破、Poc扫描、指纹识别、定时任务、管理后台识别、报表展示。 使用场景是Docker搭建好之后，设置好你要扫描的网段跟爆破任务。就不要管他了，没事过来收漏洞就行了

**功能清单**

*   masscan+namp巡航扫描资产
*   创建定时爆破任务(FTP/SSH/SMB/MSSQL/MYSQL/POSTGRESQL/MONGOD)
*   管理后台识别
*   结果导出
*   报表展示
*   docker一键部署 \[21-02-08\]
*   CMS识别 - 结合威胁情报、如果某个CMS爆出漏洞，可以快速定位企业内部有多少资产 \[21-02-20\]
*   poc扫描 - 调用xray的Poc,对新发现的资产自动扫描poc \[21-02-20\]

**预览**

tip:如果图片加载不出来,点我去gitee看图片

**首页** 

**资产列表** 

**敏感后台** 

**指纹管理** 

**任务列表** 

**任务详情** 

**xray**  

**设置** 

**管理后台识别**

不论甲方乙方。大家在渗透一个网站的时候，很多时候都想尽快找到后台地址。linglong对自己的资产库进行Title识别。然后根据title关键字、url关键字、body关键字(比如url中包含login、body中包含username/password)进行简单区分后台。帮助我们渗透中尽快锁定后台。

**指纹识别**

系统会对新发现的资产进行一遍指纹识别, 也可以手动新增指纹。比如某个CMS爆出漏洞，新增指纹扫描一遍系统中存在的资产。可以快速定位到漏洞资产，对于渗透打点或者甲方应急都是极好的

**POC扫描**

对于任何一个扫描系统，poc扫描都是必不可少的。但是poc的更新一直是所有开源项目面临的一个问题。综合考虑用Xray的poc,系统集成的XRAY版本是1.7.0,感谢Xray对安全圈做出的贡献！ linglong会对每次新发现的资产进行一遍Xray的Poc扫描。如果发现漏洞会自动入库，可以可视化查看漏洞结果

**资产巡航更新**

masscan可以无限扫描，但是对于失效资产我们也不能一直保存。linglong通过动态设置资产扫描周期，对于N个扫描周期都没有扫描到的资产会进行删除。保存资产的时效性

**安装****Docker安装****如果部署在本地体验(本地机器或者自己的虚拟机)**

如果是**本地体验**下，直接运行如下命令

git clone https://github.com/awake1t/linglong
cd linglong
docker-compose up -d

运行结束后,运行docker container ls -a看下是否运行正常

web访问 http://ip:8001 登录账号:linglong 登录密码:linglong5s

Web账号

linglong

linglong5s

类型

用户名

密码

mysql数据库

root

linglong8s

**注: 首次运行在设置里修改扫描的网段范围,点击保存后就行了。然后耐心等待系统自动扫描，扫描耗时您配置的网段+端口+速率会有变化****如果部署在服务器上(地址不是127.0.0.1情况)**

git clone https://github.com/awake1t/linglong
cd linglong/web

# 把 YourServerIp 换成你的IP地址
sed -i 's#http://127.0.0.1:18000#http://YourServerIp:18000#g' ./dist/js/app.4dccb236.js && sed -i 's#http://127.0.0.1:18000#http://YourServerIp:18000#g' ./dist/js/app.4dccb236.js.map

# 重要！！！ 如果之前安装过，使用如下命令删除所有名字包含linglong的历史镜像
docker rmi $(docker images | grep "linglong" | awk '{print $3}') 

# 返回到 linglong的目录下
cd ../
docker-compose up -d

一般这时候就部署好了,如果访问不了. 要确认下服务器上安全组的8001和18000有没有打开.

**未来**

我觉得一个好的工具就是 **拿来就用、用完既走**。后期会加入漏洞的机器人通知，发现漏洞自动通知到机器人，连你登录系统的步骤都省略。 或者看有没有方式把Goby集成。加油，干饭人！

**更新日志**

*   \[2021-0210\] 指纹资产管理、增删改查
*   \[2021-0210\] 优化资产的查询方式
*   \[2021-0213\] 发现资产POC自动扫描、扫描结果界面查看、删除
*   \[2021-0214\] 密码修改功能，关闭Xray-server-error
*   \[2021-0215\] Docker折腾了好久
*   \[2021-0225\] 更新docker-compose的部署方式

**常见问题**

**Q: 为什么安装后，点击登录没有反应？？**

A:大概率是你的部署的服务器地址不是 **127.0.0.1**, 所以会登录不上。 解决参考安装方式中： “如果部署在服务器上(地址不是127.0.0.1情况)”。 如果你的部署服务器地址是127.0.0.1,登录没反应。提供F12网络中的请求包截图，环境，部署方式到ISSUE。

**Q: 怎么知道服务器的某个端口有没有打开**

A: 比如8002端口, 在服务器上使用命令 python3 -m http.server 8002 启动一个临时WebServer. 然后在自己本地电脑 curl -v http://ip:8002 如果有返回,就代表服务器端口是开的.

**Q: 出现 Service 'web' failed to build : Error parsing reference: "nginx:1.15.3-alpine as production-stage" is not a valid repository/tag: invalid reference format？？报错**

A: docker版本过低,查看docker的版本 docker --version。 解决: 需要升级docker的版本, 我的docker版本, Docker version 19.03.4, build 9013bf5docker升级参考

**致谢**

https://github.com/ysrc/xunfeng

https://github.com/chaitin/xray

**404StarLink 2.0 - Galaxy**

linglong 是 404Team 星链计划2.0中的一环，如果对linglong 有任何疑问又或是想要找小伙伴交流，可以参考星链计划的加群方式。

*   https://github.com/knownsec/404StarLink2.0-Galaxy#community

Tag

#mongo