0 Persons are tagged with #wireshark

#wireshark

One person like that
2 Likes
tresronours@parlote.facil.services
Alexandre

Wireshark 4.2.1 Released: What’s New!

Wireshark is a popular open-source network protocol analyzer that allows users to inspect and capture data on a network in real time.

It enables detailed examination of network traffic for the following purposes:-

  • Troubleshooting

  • Analysis

  • Security purposes

  • Development

  • Education

Several key factors make Wireshark one of the leading network packet analyzers available on the internet, and here below, we have mentioned all the key factors:-

  • Open Source

  • Cross-Platform Compatibility

  • Rich Protocol Support

  • User-Friendly Interface

  • Active Community and Updates

  • Extensive Filtering capabilities

  • Search capabilities

  • Customizable Output

  • Powerful Display Filters

  • Support for Third-Party Extensions

  • Comprehensive Documentation

Free Webinar

Fastrack Compliance: The Path to ZERO-Vulnerability

Compounding the problem are zero-day vulnerabilities like the MOVEit SQLi, Zimbra XSS, and 300+ such vulnerabilities that get discovered each month. Delays in fixing these vulnerabilities lead to compliance issues, these delay can be minimized with a unique feature on AppTrana that helps you to get “Zero vulnerability report” within 72 hours.

Register for Free

However, besides this, Wireshark Foundation recently launched a new version of Wireshark, which is Wireshark 4.2.1, that brings multiple bug and vulnerability fixes.

[

#Wireshark

](https://twitter.com/hashtag/Wireshark?src=hash&ref_src=twsrc%5Etfw)

4.2.1 has been released. Enjoy.

[

https://t.co/0BETIhxQA8

](https://t.co/0BETIhxQA8)

— Wireshark Foundation (@WiresharkNews)

[

January 3, 2024

](https://twitter.com/WiresharkNews/status/1742651485215957113?ref_src=twsrc%5Etfw)

What’s New?

Vulnerability Fixes

Here below, we have mentioned all the vulnerability fixes:-

Bug Fixes

Here below we have mentioned all the bug fixes:-

  • Capture filters not saved to a recently used list. Issue 12918.

  • CFM dissector does not handle Sender ID TLV correctly when Chassis ID Length is zero. Issue 13720.

  • OSS-Fuzz 64290: wireshark:fuzzshark_ip: Global-buffer-overflow in dissect_zcl_read_attr_struct. Issue 19490.

  • Overriding capture options set by preference by command line arguments (like -S) doesn’t work. Issue 14549.

  • Segfault when enabling monitor mode on wireless card that falsely claims to support it. Issue 16693.

  • The documented format of the temporary file name is out of date in the Wireshark User’s Guide. Issue 18464.

  • Selection highlight is lost when the interface list is sorted. Issue 19133.

  • HTTP3 malformed packets. Issue 19475.

  • Capture filter compilation fails with an obscure error message. Issue 19480.

  • XML: Parsing encoding attribute failed when standalone attribute exists. Issue 19485.

  • Display filter expressions where the protocol name starts with a digit and contains a hyphen are rejected. Issue 19489.

  • diameter.3GPP-* display filters not working after upgrade to version 4.2.0. Issue 19493.

  • GigE-vision: Control Protocol shows \”unknown\” as a value for the ASCII character set. Issue 19494.

  • The HTTP/3 Request Header URI is not correct. Issue 19497.

  • QUIC/TLS not extracting \”h3\” from ALPN in a capture. Issue 19503.

  • Documentation on system requirements should be updated. Issue 19512.

  • 4.2.0: init.lua in subdirectories not loaded anymore. Issue 19516.

  • Malformed SIP/SDP messages: components are not decoded properly. Issue 19518.

  • heuristic_protos do not reset on profile swap. Issue 19520.

  • Wireshark 4.2 crashes on Apply As Column. Issue 19521.

  • NFLOG timestamp is incorrect. Issue 19525.

  • Qt6 Crash (Double Free) When Attempting to Save TCP Stream Graph. Issue 19529.

  • Fixed parsing display filter expressions containing literal OID values, e.g. snmp.name == 1.3.6.1.2.1.1.3.0.

Installation Packages

Here below we have mentioned the complete list of third-party packages that can be found on the official download page of Wireshark:-

  • Windows x64 Installer

  • Windows Arm64 Installer

  • Windows x64 PortableApps®

  • macOS Arm Disk Image

  • macOS Intel Disk Image

  • Source Code

The post Wireshark 4.2.1 Released: What’s New! appeared first on GBHackers on Security | #1 Globally Trusted Cyber Security News Platform.
posted by pod_feeder

california@diaspora.permutationsofchaos.com
California Girls Hacker

If you want to be a hacker try to understand this article in detail ...

In-Depth #Analysis of July 2023 #Exploit Chain Featuring #CVE-2023-36884 and #CVE-2023-36584
https://unit42.paloaltonetworks.com/new-cve-2023-36584-discovered-in-attack-chain-used-by-russian-apt/

Why should you care?
* Get a peek into #malware reverse engeneering
* Learn about weaponizing #attack chaining and other evils of a succesful attack
* Understand #Windows client leaks
* Exposure to #Wireshark, #pcap, #procom, ...
* Relevance for Windows #Security Zones, Mark of the Web (MotW)
* ...

#internet #hacker #hack #education #knowledge #coding #web

In-Depth Analysis of July 2023 Exploit Chain Featuring CVE-2023-36884 and CVE-2023-36584

In July 2023, pro-Russian APT Storm-0978 targeted support for Ukrainian NATO admission with an exploit chain. Analysis of it reveals the new CVE-2023-36584.

2 Likes
3 Comments
One person like that
hypolite@friendica.mrpetovan.com
Hypolite Petovan

Admittedly, I don't use a VPN, but I also actively avoid using these services. Most digital convenience is wrapped in #surveillance these days.

♲ Greg Slepak 🐢 - 2022-10-12 18:44:14 GMT

"We confirm that iOS 16 does communicate with Apple services outside an active VPN tunnel. Worse, it leaks DNS requests. #Apple services that escape the VPN connection include Health, Maps, Wallet. We used @ProtonVPN and #Wireshark. Details in the video:

#CyberSecurity #Privacy"

Via: https://twitter.com/mysk_co/status/1579997801047822336

felix@pod.pc-tiede.de
Felix Tiede

Here's another #post-mortem for you.

Tl;dr: Be sure your diagnostic tools show everything and do not hide vital information even though running in verbose or verbose-verbose mode.

First of all: My home #network is not as simple as it could be and certainly not as simple as it would be with most private users around the globe.
That brings with it its very own bunch of challenges, none of which is of any particular concern here. Suffice it to say, a regular consumer-grade internet access device (colloquially "WiFi router") would not do it. I have heavier requirements.

That in turn means my #ISP did not supply me with a real router – in fact I decline any ISP-supplied device whenever possible. Instead I bought my own device which does fulfill my requirements, in this case a semi-professional router with #PPPoE #pass-through capabilities, essentially a #DSL‌-modem.

The latter is the important part, because that is where my weekend worries began.

The modem did work for years on end with no reason for me to ever regret my decision to buy it in the first place.
Until last friday morning when it rebooted from the latest firmware upgrade.

At that very moment my internet connection dropped with a very dreaded error message from the #PPP daemon: "Timeout waiting for PADO packets."
That's tech-talk for "the ISP does no longer reply to my connection requests."

The message was already known to me and experience had me on the side of stupid coincidence which I have seen more often than I could count. So, quickly I was on the phone with the ISP requesting a port reset hoping for instant recovery.
Which didn't happen.

I'll skip the boring part of booting, downgrading, recabling and testing (even with a new OS install) for hours while other people expected me to work, but it went on until monday morning. Needless to say, I had a lot of time to think during the weekend.

I will just mention that most of the time I got beyond that PADO step, yet #pppd failed to get any replies for its #LCP configuration requests (that way I can add some more hashtags to the post, yay!).

On monday morning I finally figured I should do a real trace of the conversation appearing on the wire, for as far as #tcpdump told me not only was I sending requests, I even got answers from the ISP. Only, they were ignored by my endpoint software.
tcpdump's console output did not reveal why this should happen, a different network card, updated endpoint software - nothing actually helped. Requests were sent, replies came in and were promptly ignored.

Until I was fed up enough and decided to have a deep look into that very conversation on the wire, using #wireshark. Wireshark is a very powerful tool and its most notable feature is it doesn't hide any information by default.
And it was this now unhidden information which finally pointed me in the right direction: The oh-so-dutifully ignored replies from my ISP carried with them a #VLAN tag.

Short excursion: I am using a #VDSL landline on which the provider offers "triple-play", that is, Internet, Telephone and TV all over the same cable. For that to work technically, the ISP requires its customers to tag their "regular" outgoing internet traffic with a certain VLAN id before sending it out to the ISP. Likewise, the ISP tags all incoming internet traffic with same id.

Usually, the modem should do the tag/untag of the traffic before handing it over to the LAN, in my case to my PPP endpoint.
And it was this very tag/untag which actually stopped working.

From this point on the solution was pretty simple: If the tagging inside the modem is unreliable, the feature can be disabled (in fact, it can be configured to suit the ISP's requirements). So I did that. Now that caused the situation to deteriorate in the first step, because now nothing was coming back at all anymore. Where at least I got ignored replies from the ISP before now I got nothing.

However, #linux is capable of a lot of things, one of which is making network cards do "the right thing". In this case I reconfigured the system's network to add the required VLAN tag to everything related to the much needed PPP connection. A side effect is that the kernel now also removes the tag from any incoming frame.
At this point my PPP endpoint finally got the replies again and within seconds the connection was back up as it was designed in the first place.

Needless to say I think it's a bug in the modem's firmware, yet since downgrading did not improve the situation, it seems the bug was introduced much earlier but never manifested itself.
Also, to reference the "tl;dr" from above: Had I done the wireshark trick right from the start I probably would have stumbled over the wrong VLAN tag much earlier, saving me a lot of testing hours as well as a lot of worries on how to get the system back to its intended state.
The lesson I learned is that even though diagnostic tools can be made to be very verbose, sometimes they still skip some information vital to the issue in question and thus can not necessarily be fully trusted. It is not only important to have those tools at hand, it is quite as important to know their limitations and how to handle or overcome them.

3 Likes