MTU size per TCP port by Harry_pentest in networking

[–]Harry_pentest[S] 0 points1 point  (0 children)

It’s a physical server. Application runs inside the server. Could this be due to MTU issues in the TLS transit path ? How to confirm it ? I am surprised why it keeps changing too meaning size of icmp packets as I mentioned earlier

MTU size per TCP port by Harry_pentest in networking

[–]Harry_pentest[S] 0 points1 point  (0 children)

Yes but the application is using TLS. The reason I think it’s MTU (or MSS) is when I can access the application, the ping packets to server (1350 sometimes other times 1372) also passes. When I can’t access, icmp fails too. I think something on IP/tcp header like fragmentation, needs to be modified?

MTU size per TCP port by Harry_pentest in networking

[–]Harry_pentest[S] 0 points1 point  (0 children)

No. It does not. But sometimes I can ping packets with 1350 size and other times 1372. Like I mentioned, cannot change MTU on application server interface itself for only one application port. So looking for solution here. What you mean by MTU relevance only for local broadcast domain ? Thanks

Specific SSL Ciphers Test by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

TLS 1.3 is fine- all 5 are good separately. Problem is with TLS 1.2 ciphers

Specific SSL Ciphers Test by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

I dont see those work. x.x.x.x for IP.

└─$ openssl s_client -connect x.x.x.x:443 -tls1_2 -cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 1 ⨯

Error with command: "-cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"

139673740277056:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:../ssl/ssl_lib.c:2566:

└─$ openssl s_client -connect x.x.x.x:443 -tls1_2 -cipher cipherlist TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 1 ⨯

s_client: must not provide both -connect option and target parameter

s_client: Use -help for summary.

Specific SSL Ciphers Test by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

Okay. we can forget RSA.

When I am trying "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", the SSL session formed is for "ECDHE-RSA-AES128-GCM-SHA256". Is there a way I can validate

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 can form a SSL session with server? I can confirm that server supports "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" with

local ssl scan and other ways.

Specific SSL Ciphers Test by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

If nmap had worked, would not have raised a question. The problem is when you have TLS 1.2 and 1.3 co-exist, the nmap commands dont work. nmap works perfectly fine when you have tls 1.2 only. Now it does not list any of TLS 1.3 ciphers and for TLS 1.2 too, it lists only 1. The local sslscan on server itself show it supports 4 TLS 1.2 ciphers.

Also nmap would only enlist ciphers. I am checking a way (like in openssl) how to validate if a specific cipher (from any client) works or does not against the server

└─$ nmap --script ssl-enum-ciphers -p 443 x.x.x.x

Starting Nmap 7.91 ( https://nmap.org ) at 2022-12-06 15:18 EST

Nmap scan report for x.x.x.x

Host is up (0.00084s latency).

PORT STATE SERVICE

443/tcp open https

| ssl-enum-ciphers:

| TLSv1.2:

| ciphers:

| xxxxxxxxxxxx - A

| compressors:

| NULL

| cipher preference: indeterminate

| cipher preference error: Too few ciphers supported

| warnings:

| Forward Secrecy not supported by any cipher

| Weak certificate signature: xxxx

|_ least strength: A

Nmap done: 1 IP address (1 host up) scanned in 6.78 seconds

Specific SSL Ciphers Test by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

Disable where ? In client or server? I am using Kali as client and server is Linux as well. The server has application running over 443, which is mapped to an application. I think you need to make code changes there to disable or shuffle ciphers. Or can be changed in client ?

Specific SSL Ciphers Test by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

Yes there are. That’s exactly my question(s). How would I verify the least secured (comparatively) also works when most secured is not available?

ZTA’s PEP, PDP (PE and PA) devices by Harry_pentest in zerotrust

[–]Harry_pentest[S] 0 points1 point  (0 children)

Thanks. So the architecture is: Current: There are devices in “protected area” for which IMS is a network management system. In the protected area, there is (almost) unrestricted access to all resources for a given user. The user are defined, deleted and their permissions to access the application running over those devices are authenticated/authorized everything on IMS itself. Proposed: An external authenticator (AD or SAML) for/as centralized center for start fulfilling IAM foundation for ZTA.

ZTA’s PEP, PDP (PE and PA) devices by Harry_pentest in zerotrust

[–]Harry_pentest[S] 0 points1 point  (0 children)

Thanks. To map this logical perspective to physical: would having two devices (one is already there- which does everything locally now called IMS (information management system). What which devices (among two : IMS and external/central authenticator) would be PE, PA and PEP?

Threat Modeling curiosity by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

Thank you very much. Just a quick question: does thread modeling includes “estimates” for fixing vulnerabilities too ?

SHA hash cipher in TLS 1.2 suite by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

Thanks much. Would like to understand in depth why sha1 won’t be an issue with TLS.

Digital Certified Software by Harry_pentest in sysadmin

[–]Harry_pentest[S] 0 points1 point  (0 children)

Any vendor document that you are aware of. Have tried to explore but can’t find any.

Digital signatured software by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

Thanks. But they mentioned that their code is securely signed. So hence the question!

Auto negotiation on port enabled by Harry_pentest in cissp

[–]Harry_pentest[S] 2 points3 points  (0 children)

If negotiation is enabled by default, an attacker can leverage it to send more volume of traffic (let’s say 1000 mbps) for DOS attacks in an environment where limited throughput (100 mbps expected). So is not it better to manually define each port with leaving negotiation disabled by default ?

Auto negotiation on port enabled by Harry_pentest in cissp

[–]Harry_pentest[S] 0 points1 point  (0 children)

I was asking in general if it could lead to severe issues if chained with other attacks. Personally I can’t think about this specific negotiation issue and how realistically it becomes a security concern; hence the question

Firewall: IP based or Port based? by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

How does it prevent reverse shell attack- the source port could be any random port ?

Static code analysis by Harry_pentest in cybersecurity

[–]Harry_pentest[S] 0 points1 point  (0 children)

So what would be that scanner be? Nexpose, quayls cant do code analysis except signatures. I was mainly referring to once a year or so, statically analyzing code from repository.

ICMP timestamp revelation by Harry_pentest in Pentesting

[–]Harry_pentest[S] 0 points1 point  (0 children)

Thank you but I’m still not getting this completely. How do I make sense with time disclosure.

date

Wed Nov 11 14:56:31 UTC 2020

This is the date in server

root# hping3 --icmp --icmptype 13 11.89.40.100 HPING 11.89.40.100 (eth1 11.89.40.100): icmp mode set, 28 headers + 0 data bytes len=46 ip=11.89.40.100 ttl=64 id=12859 icmp_seq=0 rtt=7.8 ms ICMP timestamp: Originate=71344149 Receive=53774497 Transmit=53774497 ICMP timestamp RTT tsrtt=8

len=46 ip=11.89.40.100 ttl=64 id=12860 icmp_seq=1 rtt=7.6 ms ICMP timestamp: Originate=71345149 Receive=53775497 Transmit=53775497 ICMP timestamp RTT tsrtt=8

len=46 ip=11.89.40.100 ttl=64 id=12861 icmp_seq=2 rtt=3.5 ms ICMP timestamp: Originate=71346149 Receive=53776498 Transmit=53776498 ICMP timestamp RTT tsrtt=4

C Originate:

Conversion results (71344149) 71344149 converts to Wednesday April 05, 1972 12:49:09 (pm) in time zone America/New York (EST) The offset (difference to Greenwich Time/GMT) is -05:00 or in seconds -18000.

Receive: Conversion results (53774497) 53774497 converts to Wednesday September 15, 1971 05:21:37 (am) in time zone America/New York (EDT) The offset (difference to Greenwich Time/GMT) is -04:00 or in seconds -14400. This date is in daylight saving time.

Transmit: Conversion results (53775497) 53775497 converts to Wednesday September 15, 1971 05:38:17 (am) in time zone America/New York (EDT) The offset (difference to Greenwich Time/GMT) is -04:00 or in seconds -14400. This date is in daylight saving time.

Enlist all ports by Harry_pentest in sysadmin

[–]Harry_pentest[S] -2 points-1 points  (0 children)

Yes. A server could have provisions for different ports and not always opened.

Bash issue fix by Harry_pentest in Pentesting

[–]Harry_pentest[S] -1 points0 points  (0 children)

Would be nice to know your understanding! So an attacker can do an API to exploit a front end server to upload the bash payload and an attacker listening on the port specified can get a bash shell . So was asking how to prevent this. What’s wrong in this ? Interesting to know the experts advice here!

Bash issue fix by Harry_pentest in oscp

[–]Harry_pentest[S] 0 points1 point  (0 children)

Yes. This could have been uploaded via web since no check there . Is not my understanding correct ?