20.48.108.163

Regular View Raw Data
Last Seen: 2024-04-28
Tags:
cloud

GeneralInformation

Hostnames webjapaneast02.japaneast.cloudapp.azure.com
Domains azure.com 
Cloud Provider Azure
Cloud Region japaneast
Cloud Service AzureCloud
Country Japan
City Tokyo
Organization Microsoft Corporation
ISP Microsoft Corporation
ASN AS8075

Vulnerabilities

Note: the device may not be impacted by all of these issues. The vulnerabilities are implied based on the software and version.

CVE-2024-0727 Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL to crash leading to a potential Denial of Service attack Impact summary: Applications loading files in the PKCS12 format from untrusted sources might terminate abruptly. A file in PKCS12 format can contain certificates and keys and may come from an untrusted source. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly check for this case. This can lead to a NULL pointer dereference that results in OpenSSL crashing. If an application processes PKCS12 files from an untrusted source using the OpenSSL APIs then that application will be vulnerable to this issue. OpenSSL APIs that are vulnerable to this are: PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes() and PKCS12_newpass(). We have also fixed a similar issue in SMIME_write_PKCS7(). However since this function is related to writing data we do not consider it security significant. The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.
CVE-2023-5678 Issue summary: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow. Impact summary: Applications that use the functions DH_generate_key() to generate an X9.42 DH key may experience long delays. Likewise, applications that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42 DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service. While DH_check() performs all the necessary checks (as of CVE-2023-3817), DH_check_pub_key() doesn't make any of these checks, and is therefore vulnerable for excessively large P and Q parameters. Likewise, while DH_generate_key() performs a check for an excessively large P, it doesn't check for an excessively large Q. An application that calls DH_generate_key() or DH_check_pub_key() and supplies a key or parameters obtained from an untrusted source could be vulnerable to a Denial of Service attack. DH_generate_key() and DH_check_pub_key() are also called by a number of other OpenSSL functions. An application calling any of those other functions may similarly be affected. The other functions affected by this are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate(). Also vulnerable are the OpenSSL pkey command line application when using the "-pubcheck" option, as well as the OpenSSL genpkey command line application. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
CVE-2023-3817 Issue summary: Checking excessively long DH keys or parameters may be very slow. Impact summary: Applications that use the functions DH_check(), DH_check_ex() or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service. The function DH_check() performs various checks on DH parameters. After fixing CVE-2023-3446 it was discovered that a large q parameter value can also trigger an overly long computation during some of these checks. A correct q value, if present, cannot be larger than the modulus p parameter, thus it is unnecessary to perform these checks if q is larger than p. An application that calls DH_check() and supplies a key or parameters obtained from an untrusted source could be vulnerable to a Denial of Service attack. The function DH_check() is itself called by a number of other OpenSSL functions. An application calling any of those other functions may similarly be affected. The other functions affected by this are DH_check_ex() and EVP_PKEY_param_check(). Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications when using the "-check" option. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
CVE-2023-2650 Issue summary: Processing some specially crafted ASN.1 object identifiers or data containing them may be very slow. Impact summary: Applications that use OBJ_obj2txt() directly, or use any of the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message size limit may experience notable to very long delays when processing those messages, which may lead to a Denial of Service. An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers - most of which have no size limit. OBJ_obj2txt() may be used to translate an ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSL type ASN1_OBJECT) to its canonical numeric text form, which are the sub-identifiers of the OBJECT IDENTIFIER in decimal form, separated by periods. When one of the sub-identifiers in the OBJECT IDENTIFIER is very large (these are sizes that are seen as absurdly large, taking up tens or hundreds of KiBs), the translation to a decimal number in text may take a very long time. The time complexity is O(n^2) with 'n' being the size of the sub-identifiers in bytes (*). With OpenSSL 3.0, support to fetch cryptographic algorithms using names / identifiers in string form was introduced. This includes using OBJECT IDENTIFIERs in canonical numeric text form as identifiers for fetching algorithms. Such OBJECT IDENTIFIERs may be received through the ASN.1 structure AlgorithmIdentifier, which is commonly used in multiple protocols to specify what cryptographic algorithm should be used to sign or verify, encrypt or decrypt, or digest passed data. Applications that call OBJ_obj2txt() directly with untrusted data are affected, with any version of OpenSSL. If the use is for the mere purpose of display, the severity is considered low. In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS. It also impacts anything that processes X.509 certificates, including simple things like verifying its signature. The impact on TLS is relatively low, because all versions of OpenSSL have a 100KiB limit on the peer's certificate chain. Additionally, this only impacts clients, or servers that have explicitly enabled client authentication. In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects, such as X.509 certificates. This is assumed to not happen in such a way that it would cause a Denial of Service, so these versions are considered not affected by this issue in such a way that it would be cause for concern, and the severity is therefore considered low.
CVE-2023-0466 The function X509_VERIFY_PARAM_add0_policy() is documented to implicitly enable the certificate policy check when doing certificate verification. However the implementation of the function does not enable the check which allows certificates with invalid or incorrect policies to pass the certificate verification. As suddenly enabling the policy check could break existing deployments it was decided to keep the existing behavior of the X509_VERIFY_PARAM_add0_policy() function. Instead the applications that require OpenSSL to perform certificate policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly enable the policy check by calling X509_VERIFY_PARAM_set_flags() with the X509_V_FLAG_POLICY_CHECK flag argument. Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications.
CVE-2023-0465 Applications that use a non-default option when verifying certificates may be vulnerable to an attack from a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled by passing the `-policy' argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function.
CVE-2023-0464 A security vulnerability has been identified in all supported versions of OpenSSL related to the verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit this vulnerability by creating a malicious certificate chain that triggers exponential use of computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy processing is disabled by default but can be enabled by passing the `-policy' argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function.
CVE-2023-0286 There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.
CVE-2023-0215 The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications. The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO then a use-after-free will occur. This will most likely result in a crash. This scenario occurs directly in the internal function B64_write_ASN1() which may cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on the BIO. This internal function is in turn called by the public API functions PEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream, SMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7. Other public API functions that may be impacted by this include i2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream and i2d_PKCS7_bio_stream. The OpenSSL cms and smime command line applications are similarly affected.
CVE-2022-4304 A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. For example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection.
CVE-2022-2068 10.0In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehash script does not properly sanitise shell metacharacters to prevent command injection were found by code review. When the CVE-2022-1292 was fixed it was not discovered that there are other places in the script where the file names of certificates being hashed were possibly passed to a command executed through the shell. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.4 (Affected 3.0.0,3.0.1,3.0.2,3.0.3). Fixed in OpenSSL 1.1.1p (Affected 1.1.1-1.1.1o). Fixed in OpenSSL 1.0.2zf (Affected 1.0.2-1.0.2ze).
CVE-2022-1292 10.0The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd).
CVE-2022-0778 5.0The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).
CVE-2021-4160 4.3There is a carry propagation bug in the MIPS32 and MIPS64 squaring procedure. Many EC algorithms are affected, including some of the TLS 1.3 default curves. Impact was not analyzed in detail, because the pre-requisites for attack are considered unlikely and include reusing private keys. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH private key among multiple clients, which is no longer an option since CVE-2016-0701. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0.0. It was addressed in the releases of 1.1.1m and 3.0.1 on the 15th of December 2021. For the 1.0.2 release it is addressed in git commit 6fc1aaaf3 that is available to premium support customers only. It will be made available in 1.0.2zc when it is released. The issue only affects OpenSSL on MIPS platforms. Fixed in OpenSSL 3.0.1 (Affected 3.0.0). Fixed in OpenSSL 1.1.1m (Affected 1.1.1-1.1.1l). Fixed in OpenSSL 1.0.2zc-dev (Affected 1.0.2-1.0.2zb).
CVE-2021-3712 5.8ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).
CVE-2021-23841 4.3The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).
CVE-2021-23840 5.0Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).
CVE-2020-1971 4.3The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes: 1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate 2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) If an attacker can control both items being compared then that attacker could trigger a crash. For example if the attacker can trick a client or server into checking a malicious certificate against a malicious CRL then this may occur. Note that some applications automatically download CRLs based on a URL embedded in a certificate. This checking happens prior to the signatures on the certificate and CRL being verified. OpenSSL's s_server, s_client and verify tools have support for the "-crl_download" option which implements automatic CRL downloading and this attack has been demonstrated to work against those tools. Note that an unrelated bug means that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence trigger this attack. All OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL releases are out of support and have not been checked. Fixed in OpenSSL 1.1.1i (Affected 1.1.1-1.1.1h). Fixed in OpenSSL 1.0.2x (Affected 1.0.2-1.0.2w).
CVE-2020-1968 4.3The Raccoon attack exploits a flaw in the TLS specification which can lead to an attacker being able to compute the pre-master secret in connections which have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would result in the attacker being able to eavesdrop on all encrypted communications sent over that TLS connection. The attack can only be exploited if an implementation re-uses a DH secret across multiple TLS connections. Note that this issue only impacts DH ciphersuites and not ECDH ciphersuites. This issue affects OpenSSL 1.0.2 which is out of support and no longer receiving public updates. OpenSSL 1.1.1 is not vulnerable to this issue. Fixed in OpenSSL 1.0.2w (Affected 1.0.2-1.0.2v).
CVE-2019-1563 4.3In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).
CVE-2019-1559 4.3If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). Fixed in OpenSSL 1.0.2r (Affected 1.0.2-1.0.2q).
CVE-2019-1552 1.9OpenSSL has internal defaults for a directory tree where it can find a configuration file as well as certificates used for verification in TLS. This directory is most commonly referred to as OPENSSLDIR, and is configurable with the --prefix / --openssldir configuration options. For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets assume that resulting programs and libraries are installed in a Unix-like environment and the default prefix for program installation as well as for OPENSSLDIR should be '/usr/local'. However, mingw programs are Windows programs, and as such, find themselves looking at sub-directories of 'C:/usr/local', which may be world writable, which enables untrusted users to modify OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules, etc. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows targets, including Visual C builds. However, some build instructions for the diverse Windows targets on 1.0.2 encourage you to specify your own --prefix. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).
CVE-2019-1551 5.0There is an overflow bug in the x64_64 Montgomery squaring procedure used in exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway. Also applications directly using the low level API BN_mod_exp may be affected if they use BN_FLG_CONSTTIME. Fixed in OpenSSL 1.1.1e (Affected 1.1.1-1.1.1d). Fixed in OpenSSL 1.0.2u (Affected 1.0.2-1.0.2t).
CVE-2019-1547 1.9Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).
CVE-2019-11072 9.8lighttpd before 1.4.54 has a signed integer overflow, which might allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a malicious HTTP GET request, as demonstrated by mishandling of /%2F? in burl_normalize_2F_to_slash_fix in burl.c. NOTE: The developer states "The feature which can be abused to cause the crash is a new feature in lighttpd 1.4.50, and is not enabled by default. It must be explicitly configured in the config file (e.g. lighttpd.conf). Certain input will trigger an abort() in lighttpd when that feature is enabled. lighttpd detects the underflow or realloc() will fail (in both 32-bit and 64-bit executables), also detected in lighttpd. Either triggers an explicit abort() by lighttpd. This is not exploitable beyond triggering the explicit abort() with subsequent application exit.
CVE-2018-5407 1.9Simultaneous Multi-threading (SMT) in processors can enable local users to exploit software vulnerable to timing attacks via a side-channel timing attack on 'port contention'.
CVE-2018-19052 7.5An issue was discovered in mod_alias_physical_handler in mod_alias.c in lighttpd before 1.4.50. There is potential ../ path traversal of a single directory above an alias target, with a specific mod_alias configuration where the matched alias lacks a trailing '/' character, but the alias target filesystem path does have a trailing '/' character.
CVE-2018-0739 4.3Constructed ASN.1 types with a recursive definition (such as can be found in PKCS7) could eventually exceed the stack given malicious input with excessive recursion. This could result in a Denial Of Service attack. There are no such structures used within SSL/TLS that come from untrusted sources so this is considered safe. Fixed in OpenSSL 1.1.0h (Affected 1.1.0-1.1.0g). Fixed in OpenSSL 1.0.2o (Affected 1.0.2b-1.0.2n).
CVE-2018-0737 4.3The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to a cache timing side channel attack. An attacker with sufficient access to mount cache timing attacks during the RSA key generation process could recover the private key. Fixed in OpenSSL 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev (Affected 1.0.2b-1.0.2o).
CVE-2018-0734 4.3The OpenSSL DSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Fixed in OpenSSL 1.1.1a (Affected 1.1.1). Fixed in OpenSSL 1.1.0j (Affected 1.1.0-1.1.0i). Fixed in OpenSSL 1.0.2q (Affected 1.0.2-1.0.2p).
CVE-2018-0732 5.0During key agreement in a TLS handshake using a DH(E) based ciphersuite a malicious server can send a very large prime value to the client. This will cause the client to spend an unreasonably long period of time generating a key for this prime resulting in a hang until the client has finished. This could be exploited in a Denial Of Service attack. Fixed in OpenSSL 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev (Affected 1.0.2-1.0.2o).
CVE-2017-3738 4.3There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. OpenSSL version 1.0.2-1.0.2m and 1.1.0-1.1.0g are affected. Fixed in OpenSSL 1.0.2n. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available. The fix is also available in commit e502cc86d in the OpenSSL git repository.
CVE-2017-3737 4.3OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.
CVE-2017-3736 4.0There is a carry propagating bug in the x86_64 Montgomery squaring procedure in OpenSSL before 1.0.2m and 1.1.0 before 1.1.0g. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen.
CVE-2017-3735 5.0While parsing an IPAddressFamily extension in an X.509 certificate, it is possible to do a one-byte overread. This would result in an incorrect text display of the certificate. This bug has been present since 2006 and is present in all versions of OpenSSL before 1.0.2m and 1.1.0g.
CVE-2009-3767 4.3libraries/libldap/tls_o.c in OpenLDAP 2.2 and 2.4, and possibly other versions, when OpenSSL is used, does not properly handle a '\0' character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408.
CVE-2009-3766 6.8mutt_ssl.c in mutt 1.5.16 and other versions before 1.5.19, when OpenSSL is used, does not verify the domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.
CVE-2009-3765 6.8mutt_ssl.c in mutt 1.5.19 and 1.5.20, when OpenSSL is used, does not properly handle a '\0' character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408.
CVE-2009-1390 6.8Mutt 1.5.19, when linked against (1) OpenSSL (mutt_ssl.c) or (2) GnuTLS (mutt_ssl_gnutls.c), allows connections when only one TLS certificate in the chain is accepted instead of verifying the entire chain, which allows remote attackers to spoof trusted servers via a man-in-the-middle attack.
-810014905 | 2024-04-28T06:45:14.297627
  
11 / tcp
-810014905 | 2024-04-28T09:21:18.286491
  
13 / tcp
-810014905 | 2024-04-26T10:30:10.413595
  
15 / tcp
-810014905 | 2024-04-27T05:41:45.112418
  
17 / tcp
-810014905 | 2024-04-26T05:20:25.399061
  
19 / tcp
-810014905 | 2024-04-25T04:10:03.331206
  
21 / tcp
-810014905 | 2024-04-27T04:01:29.377657
  
22 / tcp
1678348498 | 2024-04-28T07:17:09.011559
  
25 / tcp
-810014905 | 2024-04-24T05:31:41.725605
  
26 / tcp
-810014905 | 2024-04-26T05:38:54.020383
  
37 / tcp
1678348498 | 2024-04-28T07:06:29.362281
  
43 / tcp
-810014905 | 2024-04-27T04:32:42.665106
  
49 / tcp
-810014905 | 2024-04-28T06:22:25.549063
  
53 / tcp
-810014905 | 2024-04-28T19:11:19.029713
  
80 / tcp
-810014905 | 2024-04-28T06:00:51.774721
  
81 / tcp
-810014905 | 2024-04-25T04:20:35.467194
  
82 / tcp
-810014905 | 2024-04-26T10:44:19.830341
  
83 / tcp
-810014905 | 2024-04-26T09:38:11.092451
  
84 / tcp
-810014905 | 2024-04-27T07:42:46.657781
  
88 / tcp
-810014905 | 2024-04-22T04:18:27.196698
  
91 / tcp
-810014905 | 2024-04-28T04:28:04.999131
  
102 / tcp
-810014905 | 2024-04-28T09:20:12.661134
  
104 / tcp
-810014905 | 2024-04-27T07:21:05.015101
  
110 / tcp
-810014905 | 2024-04-28T08:38:04.866443
  
111 / tcp
1678348498 | 2024-04-25T10:31:57.119056
  
113 / tcp
-810014905 | 2024-04-28T06:56:38.747078
  
119 / tcp
-810014905 | 2024-04-27T08:50:33.780059
  
143 / tcp
-810014905 | 2024-04-26T06:10:13.559807
  
175 / tcp
-810014905 | 2024-04-26T06:26:06.996231
  
179 / tcp
-810014905 | 2024-04-28T04:19:39.803228
  
195 / tcp
-810014905 | 2024-04-26T06:57:40.871860
  
221 / tcp
-810014905 | 2024-04-28T09:25:10.435637
  
264 / tcp
1678348498 | 2024-04-28T06:45:28.562860
  
389 / tcp
-810014905 | 2024-04-28T18:42:33.171599
  
443 / tcp
-810014905 | 2024-04-25T10:37:04.298348
  
444 / tcp
-810014905 | 2024-04-26T06:55:33.736133
  
445 / tcp
-810014905 | 2024-04-28T05:06:27.250102
  
465 / tcp
-810014905 | 2024-04-24T10:36:55.057948
  
502 / tcp
-810014905 | 2024-04-28T07:28:19.835642
  
503 / tcp
1678348498 | 2024-04-28T09:09:39.918333
  
515 / tcp
-810014905 | 2024-04-28T07:53:04.605005
  
548 / tcp
1678348498 | 2024-04-27T04:29:32.784211
  
554 / tcp
1678348498 | 2024-04-26T08:31:48.865678
  
587 / tcp
-689025513 | 2024-04-28T08:53:08.217302
  
593 / tcp
-810014905 | 2024-04-25T05:07:24.867813
  
631 / tcp
-810014905 | 2024-04-28T04:23:16.553714
  
636 / tcp
-810014905 | 2024-04-28T06:57:18.500648
  
771 / tcp
-810014905 | 2024-04-26T04:51:39.302877
  
789 / tcp
-810014905 | 2024-04-28T04:45:36.425728
  
873 / tcp
-810014905 | 2024-04-26T10:38:00.313454
  
992 / tcp
-810014905 | 2024-04-24T09:06:57.248686
  
993 / tcp
-810014905 | 2024-04-27T08:46:25.763961
  
995 / tcp
-810014905 | 2024-04-26T04:18:47.790988
  
1024 / tcp
-810014905 | 2024-04-27T07:40:18.429402
  
1025 / tcp
-810014905 | 2024-04-12T06:53:06.085925
  
1026 / tcp
1678348498 | 2024-04-28T05:57:11.927801
  
1153 / tcp
-810014905 | 2024-04-26T10:11:54.911934
  
1200 / tcp
-1217057481 | 2024-04-27T05:49:17.071178
  
1234 / tcp
-810014905 | 2024-04-26T06:40:55.657488
  
1311 / tcp
-810014905 | 2024-04-28T08:38:20.776647
  
1400 / tcp
-810014905 | 2024-04-28T05:35:33.191537
  
1433 / tcp
-810014905 | 2024-04-28T09:25:10.198639
  
1471 / tcp
-810014905 | 2024-04-27T04:35:48.094414
  
1521 / tcp
1678348498 | 2024-04-28T05:43:18.836588
  
1599 / tcp
-810014905 | 2024-04-26T08:00:02.751551
  
1604 / tcp
-810014905 | 2024-04-27T05:13:04.359818
  
1723 / tcp
-810014905 | 2024-04-27T07:09:52.327805
  
1741 / tcp
1678348498 | 2024-04-08T10:11:04.964881
  
1800 / tcp
-810014905 | 2024-04-27T05:04:45.847640
  
1801 / tcp
1678348498 | 2024-04-28T09:25:07.172184
  
1911 / tcp
-810014905 | 2024-04-28T05:59:39.857819
  
1925 / tcp
-810014905 | 2024-04-27T07:30:10.291484
  
1935 / tcp
-810014905 | 2024-04-18T06:19:10.410417
  
1947 / tcp
-810014905 | 2024-04-05T07:11:35.752768
  
1950 / tcp
-810014905 | 2024-04-27T04:44:03.549726
  
1962 / tcp
1678348498 | 2024-04-28T08:32:20.515769
  
2000 / tcp
-810014905 | 2024-04-23T07:01:31.760906
  
2002 / tcp
-810014905 | 2024-04-02T07:40:42.950110
  
2050 / tcp
-810014905 | 2024-04-22T07:43:28.162596
  
2058 / tcp
-810014905 | 2024-04-23T06:44:06.061523
  
2067 / tcp
-810014905 | 2024-04-26T06:52:46.493516
  
2081 / tcp
-810014905 | 2024-04-24T09:47:20.223723
  
2082 / tcp
-810014905 | 2024-04-25T10:45:26.010170
  
2086 / tcp
1678348498 | 2024-04-28T05:19:56.286861
  
2087 / tcp
-810014905 | 2024-04-25T08:54:28.045348
  
2121 / tcp
-810014905 | 2024-04-28T08:05:58.689249
  
2154 / tcp
1678348498 | 2024-04-28T05:00:29.220294
  
2181 / tcp
-810014905 | 2024-04-28T04:32:30.769867
  
2222 / tcp
-810014905 | 2024-04-27T06:43:28.045013
  
2375 / tcp
-1445837633 | 2024-04-28T08:11:12.427355
  
2379 / tcp
-810014905 | 2024-04-28T07:48:45.418339
  
2404 / tcp
-810014905 | 2024-04-25T10:07:55.060902
  
2455 / tcp
-810014905 | 2024-04-27T04:50:15.520028
  
2480 / tcp
-810014905 | 2024-04-19T06:07:51.289997
  
2555 / tcp
-810014905 | 2024-04-20T07:31:24.935915
  
2602 / tcp
1678348498 | 2024-04-26T04:43:13.924415
  
2628 / tcp
-810014905 | 2024-04-26T10:37:38.343735
  
2761 / tcp
-810014905 | 2024-04-28T07:22:07.275655
  
2762 / tcp
-810014905 | 2024-04-28T06:02:15.789696
  
3000 / tcp
1678348498 | 2024-04-28T07:09:58.272287
  
3001 / tcp
1678348498 | 2024-04-28T08:43:50.219749
  
3050 / tcp
-810014905 | 2024-04-27T05:51:01.657422
  
3052 / tcp
-810014905 | 2024-04-25T08:54:44.250633
  
3069 / tcp
-810014905 | 2024-04-05T09:16:58.368171
  
3095 / tcp
-810014905 | 2024-04-10T07:34:16.884447
  
3110 / tcp
-810014905 | 2024-04-28T04:25:37.400992
  
3128 / tcp
-810014905 | 2024-04-08T09:34:26.364997
  
3211 / tcp
-810014905 | 2024-04-28T07:18:57.567600
  
3260 / tcp
1678348498 | 2024-04-27T09:05:14.843985
  
3268 / tcp
-810014905 | 2024-04-27T06:25:00.149521
  
3269 / tcp
-810014905 | 2024-04-25T09:42:27.031670
  
3299 / tcp
-810014905 | 2024-04-26T08:09:58.166946
  
3301 / tcp
118557264 | 2024-04-28T08:10:04.391292
  
3306 / tcp
1678348498 | 2024-04-27T07:12:47.421399
  
3310 / tcp
-810014905 | 2024-04-15T09:17:01.734920
  
3333 / tcp
1678348498 | 2024-04-28T08:52:52.675211
  
3388 / tcp
1678348498 | 2024-04-28T04:34:29.217684
  
3389 / tcp
-810014905 | 2024-04-28T06:32:14.187625
  
3400 / tcp
-810014905 | 2024-04-23T08:15:51.211031
  
3524 / tcp
-810014905 | 2024-04-28T09:18:22.712097
  
3541 / tcp
-810014905 | 2024-04-27T08:22:59.463114
  
3542 / tcp
-810014905 | 2024-04-27T04:41:27.927951
  
3551 / tcp
-810014905 | 2024-04-10T04:45:47.400072
  
3562 / tcp
-810014905 | 2024-04-23T05:57:00.332142
  
3689 / tcp
-810014905 | 2024-04-28T05:07:42.122318
  
3749 / tcp
-810014905 | 2024-04-24T04:12:18.858442
  
3922 / tcp
-810014905 | 2024-04-11T08:34:58.018836
  
3951 / tcp
1678348498 | 2024-04-23T04:52:09.434961
  
4000 / tcp
877773046 | 2024-04-25T09:21:46.040188
  
4022 / tcp
-810014905 | 2024-04-28T09:01:41.095094
  
4040 / tcp
-810014905 | 2024-04-28T07:49:20.296660
  
4063 / tcp
-810014905 | 2024-04-28T04:56:52.617818
  
4064 / tcp
-810014905 | 2024-04-12T08:24:12.125178
  
4200 / tcp
-810014905 | 2024-04-27T05:33:20.071866
  
4242 / tcp
-810014905 | 2024-04-02T04:57:10.209633
  
4282 / tcp
-810014905 | 2024-04-28T04:31:16.097801
  
4321 / tcp
-810014905 | 2024-04-27T08:05:16.437372
  
4369 / tcp
1678348498 | 2024-04-28T09:11:31.067221
  
4500 / tcp
-1445837633 | 2024-04-28T08:13:40.604759
  
4506 / tcp
-810014905 | 2024-04-28T07:56:44.943398
  
4567 / tcp
-810014905 | 2024-04-28T06:11:49.093158
  
4664 / tcp
-810014905 | 2024-04-10T05:27:40.431897
  
4700 / tcp
-810014905 | 2024-04-26T06:59:44.870192
  
4782 / tcp
-810014905 | 2024-04-27T09:08:03.094498
  
4786 / tcp
-810014905 | 2024-04-26T10:43:54.628367
  
4840 / tcp
-810014905 | 2024-04-26T11:03:34.354833
  
4848 / tcp
-810014905 | 2024-04-27T06:56:04.087217
  
4899 / tcp
-810014905 | 2024-04-26T08:03:50.546657
  
4911 / tcp
-810014905 | 2024-04-28T07:20:32.096516
  
5000 / tcp
-810014905 | 2024-04-28T05:07:07.581696
  
5005 / tcp
1678348498 | 2024-04-28T08:16:00.595090
  
5007 / tcp
-810014905 | 2024-04-26T11:03:40.673997
  
5009 / tcp
-810014905 | 2024-04-26T09:45:15.854917
  
5010 / tcp
-810014905 | 2024-04-16T11:07:11.499806
  
5090 / tcp
-1634969874 | 2024-04-28T07:08:38.388753
  
5172 / tcp
-810014905 | 2024-04-26T10:52:40.572047
  
5201 / tcp
-810014905 | 2024-04-27T04:27:10.135369
  
5222 / tcp
-810014905 | 2024-04-27T05:36:05.687393
  
5269 / tcp
-810014905 | 2024-04-28T08:49:11.390704
  
5357 / tcp
-810014905 | 2024-04-27T07:12:15.831695
  
5435 / tcp
-810014905 | 2024-04-05T07:29:00.118367
  
5500 / tcp
-810014905 | 2024-04-27T08:08:23.434316
  
5555 / tcp
1667249752 | 2024-04-28T09:26:21.849953
  
5560 / tcp
-810014905 | 2024-04-28T09:14:38.976976
  
5601 / tcp
-810014905 | 2024-04-28T08:05:36.008041
  
5672 / tcp
-810014905 | 2024-04-26T11:03:19.407479
  
5800 / tcp
-810014905 | 2024-04-28T07:17:14.483075
  
5801 / tcp
-810014905 | 2024-04-28T08:44:12.447598
  
5858 / tcp
-810014905 | 2024-04-27T07:03:52.850152
  
5900 / tcp
-810014905 | 2024-04-28T05:38:40.009957
  
5901 / tcp
-810014905 | 2024-04-28T07:05:10.561070
  
5938 / tcp
-400265227 | 2024-04-26T07:28:17.943932
  
5984 / tcp
-810014905 | 2024-04-28T08:21:56.560071
  
5985 / tcp
-810014905 | 2024-04-05T09:01:03.350678
  
5990 / tcp
-810014905 | 2024-04-27T07:03:24.488124
  
6000 / tcp
-810014905 | 2024-04-23T04:20:48.550752
  
6001 / tcp
-810014905 | 2024-04-10T08:57:28.442660
  
6002 / tcp
-810014905 | 2024-04-21T04:55:41.776624
  
6005 / tcp
-810014905 | 2024-04-16T05:28:24.912879
  
6006 / tcp
-810014905 | 2024-04-25T07:06:06.879601
  
6080 / tcp
-810014905 | 2024-04-23T07:08:01.068967
  
6102 / tcp
-810014905 | 2024-04-15T10:41:39.387785
  
6262 / tcp
-6656507 | 2024-04-26T07:01:19.323240
  
6379 / tcp
-810014905 | 2024-04-16T04:41:23.106217
  
6443 / tcp
-810014905 | 2024-04-27T08:55:31.744437
  
6633 / tcp
-810014905 | 2024-04-28T04:55:53.449307
  
6653 / tcp
-810014905 | 2024-04-26T09:23:20.135668
  
6664 / tcp
-810014905 | 2024-04-28T08:09:50.212537
  
6666 / tcp
1678348498 | 2024-04-26T06:50:14.778484
  
6668 / tcp
-810014905 | 2024-04-26T10:29:28.211214
  
6697 / tcp
-810014905 | 2024-04-25T06:23:43.009866
  
7171 / tcp
-810014905 | 2024-04-25T06:54:01.409336
  
7218 / tcp
-810014905 | 2024-04-04T09:56:17.181188
  
7465 / tcp
-810014905 | 2024-04-28T04:48:34.381112
  
7474 / tcp
-810014905 | 2024-04-28T05:14:45.083098
  
7547 / tcp
-810014905 | 2024-04-26T10:53:37.737792
  
7657 / tcp
-810014905 | 2024-04-28T09:30:04.312635
  
7777 / tcp
-810014905 | 2024-04-21T07:13:21.521148
  
7778 / tcp
-810014905 | 2024-04-27T06:01:53.009029
  
7779 / tcp
-810014905 | 2024-04-28T08:17:06.090829
  
7989 / tcp
-810014905 | 2024-04-28T04:40:36.965737
  
8000 / tcp
-810014905 | 2024-04-27T08:12:07.023482
  
8001 / tcp
-810014905 | 2024-04-28T04:03:20.882594
  
8008 / tcp
-810014905 | 2024-04-28T07:26:27.765588
  
8009 / tcp
-810014905 | 2024-04-24T08:39:02.393202
  
8010 / tcp
-810014905 | 2024-04-11T06:54:46.167884
  
8034 / tcp
-810014905 | 2024-04-03T04:12:07.103495
  
8041 / tcp
-810014905 | 2024-04-20T06:53:06.661400
  
8045 / tcp
-810014905 | 2024-04-24T09:59:22.696509
  
8060 / tcp
-810014905 | 2024-04-10T08:47:07.085651
  
8066 / tcp
-810014905 | 2024-04-27T06:55:32.526504
  
8069 / tcp
-810014905 | 2024-04-28T06:07:13.867366
  
8080 / tcp
-810014905 | 2024-04-26T07:20:53.744471
  
8086 / tcp
-810014905 | 2024-04-26T09:39:07.850075
  
8087 / tcp
-810014905 | 2024-04-26T09:23:13.146488
  
8090 / tcp
-810014905 | 2024-04-25T09:06:43.500855
  
8098 / tcp
-810014905 | 2024-04-28T04:49:10.108523
  
8099 / tcp
-810014905 | 2024-04-28T07:59:35.999294
  
8112 / tcp
-810014905 | 2024-04-28T07:53:33.501168
  
8123 / tcp
1678348498 | 2024-04-28T05:51:09.712150
  
8126 / tcp
1667249752 | 2024-04-28T09:22:27.467759
  
8200 / tcp
-810014905 | 2024-04-10T06:57:12.565673
  
8238 / tcp
-810014905 | 2024-04-28T07:22:52.125823
  
8291 / tcp
-810014905 | 2024-04-26T11:02:04.321178
  
8333 / tcp
-810014905 | 2024-04-28T04:53:58.926476
  
8334 / tcp
-810014905 | 2024-04-08T08:33:46.409345
  
8426 / tcp
-810014905 | 2024-04-04T04:19:09.359717
  
8430 / tcp
1919282318 | 2024-04-27T06:43:12.666600
  
8500 / tcp
-810014905 | 2024-04-26T09:25:30.965873
  
8545 / tcp
1678348498 | 2024-04-28T04:18:38.009175
  
8554 / tcp
-810014905 | 2024-04-28T07:55:42.625694
  
8575 / tcp
-810014905 | 2024-04-08T09:59:49.930658
  
8623 / tcp
-810014905 | 2024-04-28T07:30:19.669942
  
8649 / tcp
-810014905 | 2024-04-08T07:42:10.759680
  
8666 / tcp
-810014905 | 2024-04-21T05:44:29.613963
  
8728 / tcp
-810014905 | 2024-04-28T05:45:54.642786
  
8800 / tcp
-810014905 | 2024-04-12T07:40:06.623353
  
8816 / tcp
-810014905 | 2024-04-21T06:46:21.541285
  
8818 / tcp
-810014905 | 2024-04-22T09:09:29.004589
  
8860 / tcp
-810014905 | 2024-04-15T04:02:40.379953
  
8887 / tcp
-810014905 | 2024-04-28T08:51:01.850985
  
8888 / tcp
-810014905 | 2024-04-15T10:53:52.204653
  
8899 / tcp
-810014905 | 2024-04-28T07:36:55.838576
  
9000 / tcp
-810014905 | 2024-04-28T07:13:39.679660
  
9009 / tcp
-810014905 | 2024-04-12T04:48:12.113594
  
9013 / tcp
-810014905 | 2024-04-23T05:49:16.023135
  
9037 / tcp
-810014905 | 2024-04-17T08:07:58.438012
  
9041 / tcp
1678348498 | 2024-04-26T10:50:18.987026
  
9051 / tcp
-810014905 | 2024-04-13T05:08:31.180298
  
9070 / tcp
-810014905 | 2024-04-25T08:11:59.281394
  
9080 / tcp
-810014905 | 2024-04-28T08:15:25.311266
  
9090 / tcp
-810014905 | 2024-04-25T10:43:51.207511
  
9092 / tcp
1678348498 | 2024-04-28T05:28:06.273198
  
9100 / tcp
-810014905 | 2024-04-24T09:59:22.636797
  
9136 / tcp
1678348498 | 2024-04-28T08:08:57.283917
  
9151 / tcp
-810014905 | 2024-04-28T08:42:38.755406
  
9160 / tcp
-810014905 | 2024-04-26T07:09:18.244912
  
9191 / tcp
-810014905 | 2024-04-28T07:25:06.079409
  
9200 / tcp
-810014905 | 2024-04-28T07:05:49.545975
  
9215 / tcp
-810014905 | 2024-04-25T06:28:38.393003
  
9295 / tcp
-810014905 | 2024-04-27T08:27:08.552610
  
9306 / tcp
-810014905 | 2024-04-25T07:41:45.428771
  
9307 / tcp
-810014905 | 2024-04-28T06:56:53.265534
  
9418 / tcp
-810014905 | 2024-04-28T04:20:15.787644
  
9530 / tcp
-810014905 | 2024-04-26T08:28:29.283870
  
9595 / tcp
-810014905 | 2024-04-26T06:04:29.162079
  
9600 / tcp
-810014905 | 2024-04-28T06:40:00.754015
  
9761 / tcp
-810014905 | 2024-04-28T06:11:01.940023
  
9800 / tcp
-810014905 | 2024-04-28T08:56:25.466696
  
9869 / tcp
-810014905 | 2024-03-31T11:14:40.926439
  
9876 / tcp
-810014905 | 2024-04-28T06:03:24.401739
  
9944 / tcp
-810014905 | 2024-04-13T11:06:48.056590
  
9966 / tcp
-810014905 | 2024-04-28T06:28:01.433085
  
9981 / tcp
-810014905 | 2024-04-12T08:43:44.931856
  
9988 / tcp
-810014905 | 2024-04-28T07:15:49.345715
  
9998 / tcp
-810014905 | 2024-04-28T07:27:14.358557
  
10001 / tcp
1678348498 | 2024-04-15T05:55:11.054400
  
10134 / tcp
-810014905 | 2024-04-26T08:55:45.713224
  
10243 / tcp
1678348498 | 2024-04-28T08:41:17.958095
  
10554 / tcp
-810014905 | 2024-04-26T10:00:51.091275
  
11112 / tcp
-810014905 | 2024-04-25T10:27:41.107467
  
11210 / tcp
-810014905 | 2024-04-28T04:09:44.323162
  
11211 / tcp
-810014905 | 2024-04-27T08:21:14.745884
  
11300 / tcp
-810014905 | 2024-04-28T07:59:17.258318
  
11371 / tcp
-810014905 | 2024-04-15T09:18:25.666795
  
11434 / tcp
-810014905 | 2024-04-28T07:19:51.784745
  
12000 / tcp
-810014905 | 2024-04-28T08:33:19.787901
  
13579 / tcp
-810014905 | 2024-04-28T08:38:58.603194
  
14147 / tcp
-810014905 | 2024-04-27T07:28:53.225159
  
14265 / tcp
1678348498 | 2024-04-05T04:50:45.782468
  
14344 / tcp
-810014905 | 2024-04-22T04:32:00.808430
  
16030 / tcp
-810014905 | 2024-04-27T04:33:22.992195
  
16992 / tcp
-810014905 | 2024-04-27T06:56:32.969428
  
18081 / tcp
-810014905 | 2024-04-27T08:52:53.888304
  
18245 / tcp
-810014905 | 2024-04-28T07:56:43.232262
  
19000 / tcp
-810014905 | 2024-04-28T08:43:06.703479
  
19071 / tcp
1678348498 | 2024-04-23T09:29:06.737018
  
20000 / tcp
-810014905 | 2024-04-28T04:47:05.664922
  
20256 / tcp
-810014905 | 2024-04-28T05:09:05.894850
  
20547 / tcp
-810014905 | 2024-04-27T06:39:01.678154
  
21379 / tcp
-810014905 | 2024-04-25T09:38:06.120006
  
23424 / tcp
-810014905 | 2024-04-27T08:24:43.335020
  
25001 / tcp
-810014905 | 2024-04-24T09:54:20.878218
  
25105 / tcp
-810014905 | 2024-04-28T09:19:05.610306
  
25565 / tcp
-810014905 | 2024-04-26T04:03:35.329492
  
27017 / tcp
-810014905 | 2024-04-28T05:53:31.278865
  
28015 / tcp
-810014905 | 2024-04-27T06:25:59.386777
  
28017 / tcp
-810014905 | 2024-04-28T06:37:56.906150
  
32400 / tcp
-810014905 | 2024-04-26T10:47:05.359225
  
32764 / tcp
-810014905 | 2024-04-27T07:30:29.089873
  
33060 / tcp
-810014905 | 2024-04-26T06:06:53.127175
  
35000 / tcp
-810014905 | 2024-04-26T04:38:20.441149
  
37215 / tcp
-810014905 | 2024-04-25T06:41:56.045774
  
37777 / tcp
-810014905 | 2024-04-28T06:02:29.424572
  
41800 / tcp
-810014905 | 2024-04-27T04:29:08.535058
  
44158 / tcp
-810014905 | 2024-04-28T08:03:29.477813
  
44818 / tcp
-810014905 | 2024-04-28T05:59:42.535344
  
49152 / tcp
-810014905 | 2024-04-26T09:06:34.843866
  
49153 / tcp
2139614848 | 2024-04-28T08:10:30.021160
  
50000 / tcp
-810014905 | 2024-04-26T10:02:24.634973
  
50050 / tcp
-810014905 | 2024-04-28T07:51:17.235663
  
50070 / tcp
-810014905 | 2024-04-25T10:56:52.236103
  
51106 / tcp
-810014905 | 2024-04-23T09:16:30.337253
  
51235 / tcp
-810014905 | 2024-04-25T09:28:17.382314
  
52869 / tcp
1678348498 | 2024-04-26T11:07:43.727175
  
54138 / tcp
-810014905 | 2024-04-28T05:04:06.794204
  
55000 / tcp
-810014905 | 2024-04-28T08:12:48.242878
  
55442 / tcp
-810014905 | 2024-04-28T08:09:47.113653
  
55554 / tcp
-810014905 | 2024-04-27T07:09:05.636031
  
60001 / tcp
-810014905 | 2024-04-08T07:48:11.754265
  
60010 / tcp
-810014905 | 2024-04-10T10:50:31.946247
  
60030 / tcp
1678348498 | 2024-04-27T06:03:22.357717
  
61613 / tcp
-810014905 | 2024-04-27T05:30:36.685490
  
61616 / tcp
1553167345 | 2024-04-28T04:58:06.342609
  
62078 / tcp



Contact Us

Shodan ® - All rights reserved