I'm using an API to get JSON objects, but the API formats the JSON objects within square brackets as an array and splits the objects within the array by commas. Can anyone help me with parsing this JSON with Logstash. I've pasted sample data below. "Modified" is the beginning of each new JSON object.
[
{
"Modified": "2021-08-31T13:49:00",
"Published": "2021-08-24T19:15:00",
"access": {
"authentication": "NONE",
"complexity": "MEDIUM",
"vector": "NETWORK"
},
"assigner": "psirt@adobe.com",
"capec": [
{
"id": "537",
"name": "Infiltration of Hardware Development Environment",
"prerequisites": "The victim must use email or removable media from systems running the IDE (or systems adjacent to the IDE systems). The victim must have a system running exploitable applications and/or a vulnerable configuration to allow for initial infiltration. The attacker must have working knowledge of some if not all of the components involved in the IDE system as well as the infrastructure.",
"related_weakness": [
"125"
],
"solutions": "",
"summary": "An attacker, leveraging the ability to manipulate components of primary support systems and tools within the development and production environments, inserts malicious software within the hardware and/or firmware development environment. The infiltration purpose is to alter developed hardware components in a system destined for deployment at the victim's organization, for the purpose of disruption or further compromise."
},
{
"id": "540",
"name": "Overread Buffers",
"prerequisites": "For this type of attack to be successful, a few prerequisites must be met. First, the targeted software must be written in a language that enables fine grained buffer control. (e.g., c, c++) Second, the targeted software must actually perform buffer operations and inadequately perform bounds-checking on those buffer operations. Finally, the adversary must have the capability to influence the input that guides these buffer operations.",
"related_weakness": [
"125"
],
"solutions": "",
"summary": "An adversary attacks a target by providing input that causes an application to read beyond the boundary of a defined buffer. This typically occurs when a value influencing where to start or stop reading is set to reflect positions outside of the valid memory location of the buffer. This type of attack may result in exposure of sensitive information, a system crash, or arbitrary code execution."
}
],
"cvss": 4.3,
"cvss-time": "2021-08-31T13:49:00",
"cvss-vector": "AV:N/AC:M/Au:N/C:P/I:N/A:N",
"cwe": "CWE-125",
"id": "CVE-2021-28618",
"impact": {
"availability": "NONE",
"confidentiality": "PARTIAL",
"integrity": "NONE"
},
"last-modified": "2021-08-31T13:49:00",
"references": [
"https://helpx.adobe.com/security/products/animate/apsb21-50.html"
],
"summary": "Adobe Animate version 21.0.6 (and earlier) is affected by an Out-of-bounds Read vulnerability when parsing a specially crafted file. An unauthenticated attacker could leverage this vulnerability to disclose sensitive memory information in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
"vulnerable_configuration": [
"cpe:2.3:a:adobe:animate:15.2.1.95:*:*:*:*:*:*:*",
"cpe:2.3:a:adobe:animate:20.5:*:*:*:*:*:*:*",
"cpe:2.3:a:adobe:animate:21.0:*:*:*:*:*:*:*",
"cpe:2.3:a:adobe:animate:21.0.2:*:*:*:*:*:*:*",
"cpe:2.3:a:adobe:animate:21.0.3:*:*:*:*:*:*:*",
"cpe:2.3:a:adobe:animate:21.0.4:*:*:*:*:*:*:*",
"cpe:2.3:o:microsoft:windows:-:*:*:*:*:*:*:*"
],
"vulnerable_configuration_cpe_2_2": [],
"vulnerable_product": [
"cpe:2.3:a:adobe:animate:15.2.1.95:*:*:*:*:*:*:*",
"cpe:2.3:a:adobe:animate:20.5:*:*:*:*:*:*:*",
"cpe:2.3:a:adobe:animate:21.0:*:*:*:*:*:*:*",
"cpe:2.3:a:adobe:animate:21.0.2:*:*:*:*:*:*:*",
"cpe:2.3:a:adobe:animate:21.0.3:*:*:*:*:*:*:*",
"cpe:2.3:a:adobe:animate:21.0.4:*:*:*:*:*:*:*"
]
},
{
"Modified": "2021-08-31T13:46:00",
"Published": "2021-08-05T21:15:00",
"access": {
"authentication": "NONE",
"complexity": "MEDIUM",
"vector": "NETWORK"
},
"assigner": "cve-assignments@hackerone.com",
"capec": [
{
"id": "463",
"name": "Padding Oracle Crypto Attack",
"prerequisites": "The decryption routine does not properly authenticate the message / does not verify its integrity prior to performing the decryption operation The target system leaks data (in some way) on whether a padding error has occurred when attempting to decrypt the ciphertext. The padding oracle remains available for enough time / for as many requests as needed for the adversary to decrypt the ciphertext.",
"related_weakness": [
"209",
"347",
"354",
"514",
"649",
"696"
],
"solutions": "Implementation: Do not leak information back to the user as to any cryptography (e.g., padding) encountered during decryption.",
"summary": "An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key. Any cryptosystem can be vulnerable to padding oracle attacks if the encrypted messages are not authenticated to ensure their validity prior to decryption, and then the information about padding error is leaked to the adversary. This attack technique may be used, for instance, to break CAPTCHA systems or decrypt/modify state information stored in client side objects (e.g., hidden fields or cookies). This attack technique is a side-channel attack on the cryptosystem that uses a data leak from an improperly implemented decryption routine to completely subvert the cryptosystem. The one bit of information that tells the adversary whether a padding error during decryption has occurred, in whatever form it comes, is sufficient for the adversary to break the cryptosystem. That bit of information can come in a form of an explicit error message about a padding error, a returned blank page, or even the server taking longer to respond (a timing attack). This attack can be launched cross domain where an adversary is able to use cross-domain information leaks to get the bits of information from the padding oracle from a target system / service with which the victim is communicating. To do so an adversary sends a request containing ciphertext to the target system. Due to the browser's same origin policy, the adversary is not able to see the response directly, but can use cross-domain information leak techniques to still get the information needed (i.e., information on whether or not a padding error has occurred). For instance, this can be done using \"img\" tag plus the onerror()/onload() events. The adversary's JavaScript can make web browsers to load an image on the target site, and know if the image is loaded or not. This is 1-bit information needed for the padding oracle attack to work: if the image is loaded, then it is valid padding, otherwise it is not."
},
{
"id": "145",
"name": "Checksum Spoofing",
"prerequisites": "The adversary must be able to intercept a message from the sender (keeping the recipient from getting it), modify it, and send the modified message to the recipient. The sender and recipient must use a checksum to protect the integrity of their message and transmit this checksum in a manner where the adversary can intercept and modify it. The checksum value must be computable using information known to the adversary. A cryptographic checksum, which uses a key known only to the sender and recipient, would thwart this attack.",
"related_weakness": [
"354"
],
"solutions": "",
"summary": "An adversary spoofs a checksum message for the purpose of making a payload appear to have a valid corresponding checksum. Checksums are used to verify message integrity. They consist of some value based on the value of the message they are protecting. Hash codes are a common checksum mechanism. Both the sender and recipient are able to compute the checksum based on the contents of the message. If the message contents change between the sender and recipient, the sender and recipient will compute different checksum values. Since the sender's checksum value is transmitted with the message, the recipient would know that a modification occurred. In checksum spoofing an adversary modifies the message body and then modifies the corresponding checksum so that the recipient's checksum calculation will match the checksum (created by the adversary) in the message. This would prevent the recipient from realizing that a change occurred."
},
{
"id": "75",
"name": "Manipulating Writeable Configuration Files",
"prerequisites": "Configuration files must be modifiable by the attacker",
"related_weakness": [
"346",
"349",
"353",
"354",
"713",
"77",
"99"
],
"solutions": "Design: Enforce principle of least privilege Design: Backup copies of all configuration files Implementation: Integrity monitoring for configuration files Implementation: Enforce audit logging on code and configuration promotion procedures. Implementation: Load configuration from separate process and memory space, for example a separate physical device like a CD",
"summary": "Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users."
}
],
"cvss": 4.3,
"cvss-time": "2021-08-31T13:46:00",
"cvss-vector": "AV:N/AC:M/Au:N/C:N/I:P/A:N",
"cwe": "CWE-354",
"id": "CVE-2021-22922",
"impact": {
"availability": "NONE",
"confidentiality": "NONE",
"integrity": "PARTIAL"
},
"last-modified": "2021-08-31T13:46:00",
"references": [
"https://hackerone.com/reports/1213175",
"https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FRUCW2UVNYUDZF72DQLFQR4PJEC6CF7V/"
],
"summary": "When curl is instructed to download content using the metalink feature, thecontents is verified against a hash provided in the metalink XML file.The metalink XML file points out to the client how to get the same contentfrom a set of different URLs, potentially hosted by different servers and theclient can then download the file from one or several of them. In a serial orparallel manner.If one of the servers hosting the contents has been breached and the contentsof the specific file on that server is replaced with a modified payload, curlshould detect this when the hash of the file mismatches after a completeddownload. It should remove the contents and instead try getting the contentsfrom another URL. This is not done, and instead such a hash mismatch is onlymentioned in text and the potentially malicious content is kept in the file ondisk."
}
]