Re: Log files, OpenBSD and Zero click exploits
On 2024-02-13, Peter N. M. Hansteen wrote: > On Tue, Feb 13, 2024 at 08:29:59AM +, jonathon575 wrote: >> Kindly find below log entries generated from tcpdump of the pflog. The is a >> fresh install & updated openbsd 7.4, with bare-minimum installation >> configured for a firewall. There are no x* programs installed. >> >> Feb 11 18:09:41.682345 rule 14/(match) block in on re0: 69.166.225.73.51820 >> > wan-ip.60360: [wg] initiation from 0xdd6a56bc >> Feb 11 18:09:46.754493 rule 14/(match) block in on re0: 69.166.225.73.51820 >> > wan-ip.60360: [wg] initiation from 0x963acc89 >> Feb 11 18:09:51.778525 rule 14/(match) block in on re0: 69.166.225.73.51820 >> > wan-ip.60360: [wg] initiation from 0x93d9508d >> Feb 11 18:09:56.835383 rule 14/(match) block in on re0: 69.166.225.73.51820 >> > wan-ip.60360: [wg] initiation from 0x112cf65b >> Feb 11 18:29:33.657009 rule 14/(match) block in on re0: 69.166.225.73.51820 >> > wan-ip.60360: [wg] initiation from 0x639ed21a >> Feb 11 18:29:33.657454 rule 14/(match) block in on re0: 69.166.225.73.51820 >> > wan-ip.60360: [wg] initiation from 0xb2fcd9b8 >> Feb 11 18:29:33.658140 rule 14/(match) block in on re0: 69.166.225.73.51820 >> > wan-ip.60360: [wg] initiation from 0x8ae84cca >> Feb 11 18:29:33.658808 rule 14/(match) block in on re0: 69.166.225.73.51820 >> > wan-ip.60360: [wg] initiation from 0xcbb881b7 >> Feb 11 18:29:33.659165 rule 14/(match) block in on re0: 69.166.225.73.51820 >> > wan-ip.60360: [wg] initiation from 0x612a28f8 >> Feb 11 18:29:33.659416 rule 14/(match) block in on re0: 69.166.225.73.51820 >> > wan-ip.60360: [wg] initiation from 0x49f595ec >> >> wan-ip is my wan static ip address. >> >> What does [wg] means? What does "initiation from 0xdd6a56bc"...etc. means? > > These log entries mean that your system blocked attempts from 69.166.225.73 > access to whatever wan-ip is. > > Your system recognized the traffic as attempts to initiate a WireGuard (a > sort of vpn, see https://man.openbsd.org/wg > and links therein). The attempts were blocked. Sending wireguard packets at you doesn't seem very likely to be malicious, more likely wan-ip was previously used by someone for their wireguard connections and it was reassigned to you. > Some of the things you mention may require specialized tools, but please > invest some time in learning to > properly interpret the output of the basic tools first. accton(8) and the manpages referenced in accton's "SEE ALSO" might be one place to start reading to log what's been run on a system. aide (in packagea) might be useful for detecting changed files. -- Please keep replies on the mailing list.
Re: Log files, OpenBSD and Zero click exploits
On Tue, Feb 13, 2024 at 08:29:59AM +, jonathon575 wrote: > Kindly find below log entries generated from tcpdump of the pflog. The is a > fresh install & updated openbsd 7.4, with bare-minimum installation > configured for a firewall. There are no x* programs installed. > > Feb 11 18:09:41.682345 rule 14/(match) block in on re0: 69.166.225.73.51820 > > wan-ip.60360: [wg] initiation from 0xdd6a56bc > Feb 11 18:09:46.754493 rule 14/(match) block in on re0: 69.166.225.73.51820 > > wan-ip.60360: [wg] initiation from 0x963acc89 > Feb 11 18:09:51.778525 rule 14/(match) block in on re0: 69.166.225.73.51820 > > wan-ip.60360: [wg] initiation from 0x93d9508d > Feb 11 18:09:56.835383 rule 14/(match) block in on re0: 69.166.225.73.51820 > > wan-ip.60360: [wg] initiation from 0x112cf65b > Feb 11 18:29:33.657009 rule 14/(match) block in on re0: 69.166.225.73.51820 > > wan-ip.60360: [wg] initiation from 0x639ed21a > Feb 11 18:29:33.657454 rule 14/(match) block in on re0: 69.166.225.73.51820 > > wan-ip.60360: [wg] initiation from 0xb2fcd9b8 > Feb 11 18:29:33.658140 rule 14/(match) block in on re0: 69.166.225.73.51820 > > wan-ip.60360: [wg] initiation from 0x8ae84cca > Feb 11 18:29:33.658808 rule 14/(match) block in on re0: 69.166.225.73.51820 > > wan-ip.60360: [wg] initiation from 0xcbb881b7 > Feb 11 18:29:33.659165 rule 14/(match) block in on re0: 69.166.225.73.51820 > > wan-ip.60360: [wg] initiation from 0x612a28f8 > Feb 11 18:29:33.659416 rule 14/(match) block in on re0: 69.166.225.73.51820 > > wan-ip.60360: [wg] initiation from 0x49f595ec > > wan-ip is my wan static ip address. > > What does [wg] means? What does "initiation from 0xdd6a56bc"...etc. means? These log entries mean that your system blocked attempts from 69.166.225.73 access to whatever wan-ip is. Your system recognized the traffic as attempts to initiate a WireGuard (a sort of vpn, see https://man.openbsd.org/wg and links therein). The attempts were blocked. The rest of your questions can be answered relatively easily by familiarizing yourself with the tools at hand, such as the tcpdump you have already encountered. Do read up on how syslog classfies messages and how to report which levels and so forth. Some of the things you mention may require specialized tools, but please invest some time in learning to properly interpret the output of the basic tools first. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Log files, OpenBSD and Zero click exploits
Subject: Log files and Zero click exploits Greetings, Kindly find below log entries generated from tcpdump of the pflog. The is a fresh install & updated openbsd 7.4, with bare-minimum installation configured for a firewall. There are no x* programs installed. Feb 11 18:09:41.682345 rule 14/(match) block in on re0: 69.166.225.73.51820 > wan-ip.60360: [wg] initiation from 0xdd6a56bc Feb 11 18:09:46.754493 rule 14/(match) block in on re0: 69.166.225.73.51820 > wan-ip.60360: [wg] initiation from 0x963acc89 Feb 11 18:09:51.778525 rule 14/(match) block in on re0: 69.166.225.73.51820 > wan-ip.60360: [wg] initiation from 0x93d9508d Feb 11 18:09:56.835383 rule 14/(match) block in on re0: 69.166.225.73.51820 > wan-ip.60360: [wg] initiation from 0x112cf65b Feb 11 18:29:33.657009 rule 14/(match) block in on re0: 69.166.225.73.51820 > wan-ip.60360: [wg] initiation from 0x639ed21a Feb 11 18:29:33.657454 rule 14/(match) block in on re0: 69.166.225.73.51820 > wan-ip.60360: [wg] initiation from 0xb2fcd9b8 Feb 11 18:29:33.658140 rule 14/(match) block in on re0: 69.166.225.73.51820 > wan-ip.60360: [wg] initiation from 0x8ae84cca Feb 11 18:29:33.658808 rule 14/(match) block in on re0: 69.166.225.73.51820 > wan-ip.60360: [wg] initiation from 0xcbb881b7 Feb 11 18:29:33.659165 rule 14/(match) block in on re0: 69.166.225.73.51820 > wan-ip.60360: [wg] initiation from 0x612a28f8 Feb 11 18:29:33.659416 rule 14/(match) block in on re0: 69.166.225.73.51820 > wan-ip.60360: [wg] initiation from 0x49f595ec wan-ip is my wan static ip address. What does [wg] means? What does "initiation from 0xdd6a56bc"...etc. means? Does that mean there is a malicious file/app located at those memory addresses in my system trying to initiate connection to this specific 69.166.225.73.51820 address/port? This ip address is a malicious and there are others as well we get every single time we connect to the internet. Those malicious ip addresses could also be spoofed. Other log files are not indicating anything. We always get those attacks every time when connecting to the internet, and usually happens at the initial connections. How to configure the log files to record all the activities happening on the system and especially to locate malicious activities/files including zero-click exploits...etc? I created a basic bin malware for testing purposes and copied it to the bsd system using usb. The only activity that was logged under messages was the usb attach/detach. However, the malicious file itself and its execution were not recorded at all in any of the log files. Also, for Intrusion Detection, I used mtree before and after the malware copy to the system, mtree was able to detect the file and record it under extra:, however, when I deleted the file and covered the track using dd if=/dev/zero of=/bin_location bs=1024k count=12, mtree could not detect it. That means as an IDS, mtree is defenseless against malicious files that deletes and covers its tracks. When examining citizen lab's zero-click exploits reports, almost all the malicious directories and files are stored under folders that would not be immutable such as /usr/ library directories and files. As an example, under openbsd, the folders /bin, /sbin, /usr/bin, /usr/sbin, and /etc, could be schg immutable, however, if the other folder or files configured to be schg immutable, the openbsd system would break, and when restart, it would not load. Also, the zero-click exploits for the most part do not attempt to change the files in the mentioned bin/sbin folders, rather, the exploit would copy the malware to a location that is not immutable and use those files to its malicious purposes. The zero-click exploit attacks for smartphones may be slightly different than a fixed standalone device system, as the smartphone such as ios, andriod...etc are mobile, so the malware may have to be persistence, however, for a standalone system such as a firewall, since it would be in a fixed location with static wan IP address, and especially if the device was under the telecom umbrella of a corrupted adversary, as long as they know what platform you are using, the zero-click exploit could happen almost instantly and does not have to be persistent as they would get in at every internet connection, then delete, cover tracks, and reinstating the system to an undetectable status at every internet disconnect. How to activate the log files to be able to detect such activities, How to protect openbsd from such exploits, what tools could be used in openbsd to help detect such malicious intrusion, any kernel/firewall tweaks to protect against such attacks? The rules "block all, pass out" are insufficient, and you do not have to click on any link for the attack to take place. Appreciate your kind support. John On Sunday, April 30th, 2023 at 5:23 AM, jonathon575 wrote: > Thank you Stuart. > > --
Re: Exploits
On first look I couldn't see the exploit in that old PDF being listed on the errata's. Maybe I'm being blind ;) On Sat 07 Sep 2013 19:45:38 BST, Greg Thomas wrote: Does this document still hold any truth with current OpenBSD; Come on, really? http://www.openbsd.org/errata40.html On Sat, Sep 7, 2013 at 8:13 AM, andy a...@brandwatch.com wrote: Hi everyone, I have a feeling that I may get some strong opinions on this question, so please don't flame me or anything, I'm asking because I don't know. Does this document still hold any truth with current OpenBSD; https://www.blackhat.com/presentations/bh-usa-07/Ortega/Whitepaper/bh-usa-07-ortega-WP.pdf Cheers, Andy.
Re: Exploits
Andy a...@brandwatch.com writes: On first look I couldn't see the exploit in that old PDF being listed on the errata's. Maybe I'm being blind ;) Or maybe you need to take a second look (010). The security problem is described, a workaround and a patch are available. Publishing an exact how-to-reproduce-and-expoit-a-bug isn't one of the the responsibilities of the OpenBSD project, afaik. On Sat 07 Sep 2013 19:45:38 BST, Greg Thomas wrote: Does this document still hold any truth with current OpenBSD; Come on, really? http://www.openbsd.org/errata40.html On Sat, Sep 7, 2013 at 8:13 AM, andy a...@brandwatch.com wrote: Hi everyone, I have a feeling that I may get some strong opinions on this question, so please don't flame me or anything, I'm asking because I don't know. Does this document still hold any truth with current OpenBSD; https://www.blackhat.com/presentations/bh-usa-07/Ortega/Whitepaper/bh-usa-07-ortega-WP.pdf Cheers, Andy. Ciao, -- jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Exploits
Hi everyone, I have a feeling that I may get some strong opinions on this question, so please don't flame me or anything, I'm asking because I don't know. Does this document still hold any truth with current OpenBSD; https://www.blackhat.com/presentations/bh-usa-07/Ortega/Whitepaper/bh-usa-07-ortega-WP.pdf Cheers, Andy.
Re: Exploits
Does this document still hold any truth with current OpenBSD; Come on, really? http://www.openbsd.org/errata40.html On Sat, Sep 7, 2013 at 8:13 AM, andy a...@brandwatch.com wrote: Hi everyone, I have a feeling that I may get some strong opinions on this question, so please don't flame me or anything, I'm asking because I don't know. Does this document still hold any truth with current OpenBSD; https://www.blackhat.com/presentations/bh-usa-07/Ortega/Whitepaper/bh-usa-07-ortega-WP.pdf Cheers, Andy.
Re: Exploits
You could've searched the archives. http://www.openbsd.org/errata40.html#m_dup1
Linux localhost exploits
Hello misc@, Just for laughs for those who don't work with Linux in their daily lives and to present some gray hairs to those who do: http://packetstormsecurity.com/files/121616/semtex.c (applying patched kernels at my work as we speak) Sincerely, Martijn van Duren
Re: Linux localhost exploits
Owning since 2010! 2013/5/15 Martijn van Duren martijn...@gmail.com Hello misc@, Just for laughs for those who don't work with Linux in their daily lives and to present some gray hairs to those who do: http://packetstormsecurity.com/files/121616/semtex.c (applying patched kernels at my work as we speak) Sincerely, Martijn van Duren -- Atentamente Andrés Genovez Tobar / DTIT Tel: 842388 ext 177 Perfil profesional http://lnkd.in/gcdhJE
Re: path traversal exploits
On 6/29/07, J.C. Roberts [EMAIL PROTECTED] wrote: The unarj v2.43 archiver we have for use with clamav virus scanning does not really work. The same is true for the newer 2.65 version released by the author. The problem is unarj is unable to extract with paths, hence it will overwrite files and stuff won't actually be scanned. At the moment, I've got a working port of 2.65 patched to extract with full paths. The last problem to solve is preventing path traversal exploits. I suspect that just searching for double dot .. in the to be created path string is not enough but since I've never done this sort of thing, I'm not sure where/what to ask. I would like to find a standardized, well tested way to test strings for potential path traversal sequences. Searching with google has been fruitless. If you'd be so kind as to drop kick me in the right direction, possibly example code, it would be much appreciated. Well, the only way I know of to go up a directory level is .. or softlinks that point up. So that should be all you have to check for. (and even if I`m wrong, hopefully now more people will notice your question) -Nick
Re: path traversal exploits
Nick Guenther wrote: On 6/29/07, J.C. Roberts [EMAIL PROTECTED] wrote: The unarj v2.43 archiver we have for use with clamav virus scanning does not really work. The same is true for the newer 2.65 version released by the author. The problem is unarj is unable to extract with paths, hence it will overwrite files and stuff won't actually be scanned. At the moment, I've got a working port of 2.65 patched to extract with full paths. The last problem to solve is preventing path traversal exploits. I suspect that just searching for double dot .. in the to be created path string is not enough but since I've never done this sort of thing, I'm not sure where/what to ask. I would like to find a standardized, well tested way to test strings for potential path traversal sequences. Searching with google has been fruitless. If you'd be so kind as to drop kick me in the right direction, possibly example code, it would be much appreciated. Well, the only way I know of to go up a directory level is .. or softlinks that point up. So that should be all you have to check for. (and even if I`m wrong, hopefully now more people will notice your question) Well, a slash in the beginning of path names made me overwrite my entire /etc dir with another machines configuration... However, that was with tar and not unarj... /Alexander
Re: path traversal exploits
Alexander Hall wrote: Well, a slash in the beginning of path names made me overwrite my entire /etc dir with another machines configuration... However, that was with tar and not unarj... Correcting myself after some testing. It was using pax. :-) /Alexander
Re: path traversal exploits
J.C. Roberts wrote on Fri, Jun 29, 2007 at 12:46:02PM -0700: The unarj v2.43 archiver we have for use with clamav virus scanning does not really work. The same is true for the newer 2.65 version released by the author. The problem is unarj is unable to extract with paths, hence it will overwrite files and stuff won't actually be scanned. At the moment, I've got a working port of 2.65 patched to extract with full paths. The last problem to solve is preventing path traversal exploits. I suspect that just searching for double dot .. in the to be created path string is not enough but since I've never done this sort of thing, I'm not sure where/what to ask. I just checked what Mark Dowd/John McDonald/Justin Schuh tell on path traversal vulnerabilities in The art of software security assessment. They treat this topic at several points, but don't give any reference implementation saying do it like this. If you want to keep unarj portable, keep in mind that different platforms use different path syntax: just to give two non-exhaustive examples, / vs. \ for separators and ^/ vs. ^[A-Z]:\\ for file system roots come to mind. In the following, i shall restrict myself to Unix all the same as i did too little programming on other platforms. On Unix, as far as i know, the only ways to achieve path traversal are - either starting the path with / - or including .. in the path. When checking the path, make sure to first fully concatenate it before checking it. Otherwise, dir=. + file=./myfile might get you. Check for just .., not ../ or /.. or even /../. Keep in mind that // is equivalent to /. Keep in mind that handling paths may expose other vulnerabilities besides path traversal, in particular buffer overflows or path truncation triggered by paths containing long strings like .././//. Depending on how you are using the path in the end of the day, also give thought to shell globbing (which is a much more difficult problem than just path traversal). Note shell globbing is shell dependent: Try `ls -d .*.` on ksh and bash. Finally, consider whether you only need path checking or whether you also need path normalisation. Path normalisation is considerably more difficult than just checking for path traversal. On the other hand, depending on the particular context, using realpath(3) and checking the result may or may not be a nice way to guard against path traversal. You might also consider looking at the tar(1) sources in /usr/src/bin/pax to understand how initial slashes can be handled. On the other hand, even venerable tar(1) does not bother preventing path traversal. Why? You can regard having .. in file names in the archive as a feature rather than a bug. Unless running privileged, you cannot clobber /root/.profile anyway. In case you have installed tar SUID, you get what you deserve. When running anything as root, you should only be using trusted input files anyway. Look here: [EMAIL PROTECTED] $ mkdir -p oldroot/olddir newroot/newdir [EMAIL PROTECTED] $ touch oldroot/olddir/myfile [EMAIL PROTECTED] $ cd oldroot/olddir/ [EMAIL PROTECTED] $ tar -cvf /tmp/my.tar .. .. ../olddir ../olddir/myfile [EMAIL PROTECTED] $ cd ../../newroot/newdir/ [EMAIL PROTECTED] $ tar -xvf /tmp/my.tar .. ../olddir ../olddir/myfile [EMAIL PROTECTED] $ ls [EMAIL PROTECTED] $ cd .. [EMAIL PROTECTED] $ find . . ./newdir ./olddir ./olddir/myfile I would like to find a standardized, well tested way to test strings for potential path traversal sequences. Searching with google has been fruitless. If you'd be so kind as to drop kick me in the right direction, possibly example code, it would be much appreciated. Perhaps someone more experienced can comment on this one. I'm not exactly sure, but i suspect you found nothing for the following simple reason: if all you want to do is checking for simple path traversal under Unix, m/^\// and m/\.\./ are all you need.
Re: path traversal exploits
Perhaps someone more experienced can comment on this one. I'm not exactly sure, but i suspect you found nothing for the following simple reason: if all you want to do is checking for simple path traversal under Unix, m/^\// and m/\.\./ are all you need. Except that it would make valid names like path/foo...bar/baz fail. I'd rather test for m#(?:^|/)\.\.(?:/|$)# (perl regexp) or m#^\.\.$# m#^\.\./# m#/\.\./# m#/\.\.$# Untested though. Expect it to fail or don't blame me. /Alexander
path traversal exploits
The unarj v2.43 archiver we have for use with clamav virus scanning does not really work. The same is true for the newer 2.65 version released by the author. The problem is unarj is unable to extract with paths, hence it will overwrite files and stuff won't actually be scanned. At the moment, I've got a working port of 2.65 patched to extract with full paths. The last problem to solve is preventing path traversal exploits. I suspect that just searching for double dot .. in the to be created path string is not enough but since I've never done this sort of thing, I'm not sure where/what to ask. I would like to find a standardized, well tested way to test strings for potential path traversal sequences. Searching with google has been fruitless. If you'd be so kind as to drop kick me in the right direction, possibly example code, it would be much appreciated. Kind Regards, JCR
