app.exe.14299_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.dmp
app.exe.14299_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.log
....
For remote fuzzing, artifacts may vary depending on the options chosen, but often include diffs, repro file and/or repro file directory (if input is a session with multiple packets), previous fuzzing iteration repro (prevent losing a bug in case its actually the crasher as remote fuzzing has its challenges) and crash log or brief information file. ls crashes/serverd
REMOTE_SERVER_testbox.1_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_PREV_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diff
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diffs
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.txt
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.zz

ls crashes/serverd/REMOTE_SERVER_localhost_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_1.zz REMOTE_SERVER_localhost_NNNN_2.zz
REMOTE_SERVER_testbox.1_NNNN_3.zz REMOTE_SERVER_localhost_NNNN_4.zz
golang Apparently when Golang binaries crash, they may not actually go down with a traditional SIGSEGV, even if that's what they say in the panic info (Linux tested). They may instead crash with return code 2. So I guess that's what we're going with :) I'm sure there's a better explanation out there for how this works and edge cases around it, but one can use --golang to try and catch crashes in golang binaries on Linux. litefuzz -l -c "evernote2md FUZZ" -i input/enex -o crashes/evernote2md --golang -n 100000 repros Crashing files are kept in the crashes/ directory (or otherwise specified by -o flag) along with diffs and crash info. -r and passing a repro file (or directory) with the appropriate target command line / address setup will try and reproduce the crash locally or remote. local example litefuzz -l -c "latex2rtf FUZZ" -r crashes/latex2rtf/test.tex -z local network example ./litefuzz -ls -c "./sc_serv shoutcast.conf" -a tcp://localhost:8000 -r crashes/crash.raw remote network example litefuzz -s -a tcp://host:8000 -r crashes/crash.raw remote network example (multiple packets) litefuzz -s -a tcp://localhost:22 -r repro/dir/here remove file Some targets ask for a static outfile location as part of their command line and may throw an error if that file already exists. --rmfile is an option for getting around this while fuzzing where after each fuzzing iteration, it will remove the file that was generated as a part of how the target functions. litefuzz -l -c "hdiutil makehybrid -o /tmp/test.iso -joliet -iso FUZZ" -i input/dmg --rmfile /tmp/test.iso -n 500000 -ez minimization Minimizing crashing files is an interesting activity. You can even infer how a target is parsing data by comparing a repro with a minimized version. -m and passing a repro file with the target command line or address setup will attempt to generate a minimized version of the repro which still crashes the target, but smaller and without bytes that may not be necessary. During this minimization journey, it may even find new crashes. Only local modes are supported, but this still includes local client and server modes, so you can minimize network crashes as long as we can debug them locally. For example, this request is the original repro file. GET /admin.cgi?pass=changeme&mode=debug&option=donotcrash HTTP/1.1
Host: localhost:8000
Connection: keep-alive
Authorization: Basic YWRtaW46Y2hhbmdlbWU=
Referer: http://localhost:8000/admin.cgi?mode=debug
Now take a look at it's minimized version. GET /admin.cgi?mode=debug&option=a
Authorization:s YWRtaW46Y2hhbmdlbWU
Referer:admin.cgi

___________________________
@hacking_Attack
@Hacking_Video

One can make some guesses about what the target is looking for and even the root cause of the crash. The request is most important part option= can probably be a lot of different things The Host and Connection headers aren't neccesary Authorization header parsing is just looking for the second token and doesn't care if it's explicitly presenting Basic auth Referer is necessary, but only admin.cgi and not the host or URL Anything else? Here's a bonus: passing a valid password isn't needed if the Authorization (https://www.kitploit.com/search/label/Authorization) creds are correct, and visa-versa. Since the minimization is linear and starts at the beginning of the file and goes until it hits the end, we'd only produce a repro which authenticates this way, while still discovering there are actually two options! -mm enables supermin mode. This is slower, but it will try and minimize over and over again until there's no more unnecessary bytes to remove. For fun, we can modify the repro and run it through supermin to get the maximally minimized version. GET /admin.cgi?pass=changeme&mode=debug&option=a
Referer:admin.cgi
minimization examples litefuzz -l -c "latex2rtf FUZZ" -m test.tex -z litefuzz -ls -c "./sc_serv shoutcast.conf" -a "tcp://localhost:8000" -m repro.http supermin example 582 bytes, ~0:00:00 remaining) [+] reduced crash @ pc=55555556c141 -> pc=55555557c57d to 582 bytes [+] supermin activated, continuing... @ 299/299 (1 new crashes, 582 -> 300 bytes, ~0:00:00 remaining) [+] reduced crash @ pc=55555557c57d to 300 bytes ... [+] reduced crash @ pc=555555562170 to 17 bytes @ 17/17 (2 new crashes, 17 -> 17 bytes, ~0:00:00 remaining) [+] achieved maximum minimization @ 17 bytes (test.min.tex) [RESULTS] completed (17) iterations with 2 new crashes found'>litefuzz -l -c "latex2rtf FUZZ" -mm crashes/latex2rtf/test.tex -z
...
[+] starting minimization

@ 582/582 (1 new crashes, 1145 -> 582 bytes, ~0:00:00 remaining)

[+] reduced crash @ pc=55555556c141 -> pc=55555557c57d to 582 bytes

[+] supermin activated, continuing...

@ 299/299 (1 new crashes, 582 -> 300 bytes, ~0:00:00 remaining)

[+] reduced crash @ pc=55555557c57d to 300 bytes
...
[+] reduced crash @ pc=555555562170 to 17 bytes

@ 17/17 (2 new crashes, 17 -> 17 bytes, ~0:00:00 remaining)

[+] achieved maximum minimization @ 17 bytes (test.min.tex)

[RESULTS]
completed (17) iterations with 2 new crashes found
command --cmd allows a user to specify a command to run after each iteration. This can be used to cleanup certain operations that would otherwise take up resources on the system. litefuzz -l -c "/System/Library/CoreServices/DiskImageMounter.app/Contents/MacOS/DiskImageMounter FUZZ" -i input/dmg --cmd "umount /Volumes/test.dir" --click -x 5 -n 100000 -ez examples local app quick look completed (100) iterations with (1) unique crashes and 4 dups >> check crashes/latex2rtf dir for more details'>litefuzz -l -c "latex2rtf FUZZ" -i input/tex -o crashes/latex2rtf -x 1 -n 100
--========================--
--======| litefuzz |======--
--========================--

[STATS]
run id: 3516
cmdline: latex2rtf FUZZ
crash dir: crashes/latex2rtf
input dir: input/tex
inputs: 4
iterations: 100
mutator: random(mutators)

@ 100/100 (1 crashes, 4 duplicates, ~0:00:00 remaining)

[RESULTS]
> completed (100) iterations with (1) unique crashes and 4 dups
>> check crashes/latex2rtf dir for more details
enumerating file handlers on Ubuntu $ cat /usr/share/applications/defaults.list
[Default Applications]
application/csv=libreoffice-calc.desktop
application/excel=libreoffice-calc.desktop
application/msexcel=libreoffice-calc.desktop
application/msword=libreoffice-writer.desktop
application/ogg=rhythmbox.desktop
application/oxps=org.gnome.Evince.desktop
application/postscript=org.gnome.Evince.desktop
....

___________________________
@hacking_Attack
@Hacking_Video

ps -Af | grep -ie "$1" | awk '{print $2}' | xargs kill -9
$ while :; do ./pkill.sh "Process Name /Users/test"; sleep 360; done
/Users/test (example for the first part of the path where temp files are being passed to the local GUI app, FUZZ becomes a path during execution) was chosen as you need a unique string to kill for processes, and if you only use the Process Name, it will kill the fuzzing process as it contains the Process Name too. enumerating file handlers on Windows Using the AssocQueryString (https://github.com/sec-tools/WindowsFileHandlerEnumeration/) script with the assoc command can map file extensions to default applications. .\AssocQueryString.ps1 ... .hlp :: C:\Windows\winhlp32.exe .hta :: C:\Windows\SysWOW64\mshta.exe .htm :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe .html :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe .icc :: C:\Windows\system32\colorcpl.exe .icm :: C:\Windows\system32\colorcpl.exe .imesx :: C:\Windows\system32\IME\SHARED\imesearch.exe .img :: C:\Windows\Explorer.exe .inf :: C:\Windows\system32\NOTEPAD.EXE .ini :: C:\Windows\system32\NOTEPAD.EXE .iso :: C:\Windows\Explorer.exe">C:\> .\AssocQueryString.ps1
...
.hlp :: C:\Windows\winhlp32.exe
.hta :: C:\Windows\SysWOW64\mshta.exe
.htm :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.html :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.icc :: C:\Windows\system32\colorcpl.exe
.icm :: C:\Windows\system32\colorcpl.exe
.imesx :: C:\Windows\system32\IME\SHARED\imesearch.exe
.img :: C:\Windows\Explorer.exe
.inf :: C:\Windows\system32\NOTEPAD.EXE
.ini :: C:\Windows\system32\NOTEPAD.EXE
.iso :: C:\Windows\Explorer.exe
When fuzzing on Windows, you may want to enable PageHeap and Memory Dumps for a better fuzzing experience (unless your target doesn't like them) prior to starting a new fuzzing run. sudo litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" -z sudo litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --memdump Yes, run these commands using (g)sudo on Windows to easily elevate to Admin from the console and make the registry changes needed for the features to be enabled. And this also illustrates another nuance for enabling malloc debuggers for targets: on Linux and Mac, we're using runtime environment flags which need to be passed every time to enable this feature. For Windows, we're modifying the registry so once it's passed the first time, one doesn't need to pass -z or --memdump in the fuzzing command line again (unless to disable or re-enable them). fuzz PuTTY (puttygen) (Windows) litefuzz -l -c "C:\Program Files (x86)\WinSCP\PuTTY\puttygen.exe FUZZ" -i input\ppk -x 0.5 -n 100000 -z fuzz Adobe Reader like back in the day (Windows GUI) litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe FUZZ" -i pdfs -x 3 -n 100000 -z (WinAppDbg only supports python 2, so must use py2 on Windows) note: reminder that you can enable PageHeap (https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags-and-pageheap) for the target app via -z in an elevanted prompt or using the installed sudo for gsudo (https://github.com/gerardog/gsudo) win32 package that was installed during setup litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe FUZZ" -z client quick look n Terminated ... cat /tmp/litefuzz/out padding error: need 57895 block 8 mod 7 ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: message authentication code incorrect'>litefuzz -lk -c "ssh -T test@localhost -p 2222" -a tcp://localhost:2222 -i input/ssh-cli -o crashes/ssh -p -n 250000 -z glibc
--========================--
--======| litefuzz |======--
--========================--

[STATS]
run id: 9404
cmdline: ssh -T test@localhost -p 2222
address: tcp://localhost:2222
crash dir: crashes/ssh
input dir: input/ssh-cli
inputs: 4

___________________________
@hacking_Attack
@Hacking_Video

iterations: 250000
mutator: random(mutators)

@ 73/250000 (0 crashes, 0 duplicates, ~1 day, 0:21:01 remaining)^C

resume? (y/n)> n
Terminated
...

cat /tmp/litefuzz/out
padding error: need 57895 block 8 mod 7
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: message authentication code incorrect
local client fuzz SNMP client on the localhost (Linux) litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3 remote client fuzz a remote FTP client (Linux) while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -n 100 note: depending on the target, client fuzzing may require listening on a privileged port (1-1024). In this case, on Linux you can either setcap cap_net_bind_service=+ep on the python interpreter or use sudo when running the fuzzer, on Mac just use sudo and on Windows you can run the fuzzer as Administrator to avoid any Permission Denied errors. server quick look completed (1000) iterations with (1) unique crashes and 7 dups >> check crashes/shoutcast for more details'>litefuzz -ls -c "./sc_serv shoutcast.conf" -a tcp://localhost:8000 -i input/shoutcast -o crashes/shoutcast -n 1000 -z
--========================--
--======| litefuzz |======--
--========================--

[STATS]
run id: 4001
cmdline: ./sc_serv shoutcast.conf
address: tcp://localhost:8000
crash dir: crashes/shoutcast
input dir: input/shoutcast
inputs: 3
iterations: 1000
mutator: random(mutators)

@ 1000/1000 (1 crashes, 7 duplicates, ~0:00:00 remaining)

[RESULTS]
> completed (1000) iterations with (1) unique crashes and 7 dups
>> check crashes/shoutcast for more details
local server fuzz a local Shoutcast server litefuzz -ls -c "./sc_serv shoutcast.conf" -a tcp://localhost:8000 -i input/shoutcast -o crashes/shoutcast -n 1000 -z remote server fuzz a remote SMTP server litefuzz -s -a tcp://10.0.0.11:25 -i input/smtp-req -pp -n 10000 command line usage: litefuzz.py [-h] [-l] [-k] [-s] [-c CMDLINE] [-i INPUTS] [-n ITERATIONS] [-x MAXTIME] [--mutator MUTATOR] [-a ADDRESS] [-o CRASHDIR] [-t TEMPDIR] [-f FUZZFILE]
[-m MINFILE] [-mm SUPERMIN] [-r REPROFILE] [-e] [-p] [-pp] [-u] [--nofuzz] [--key KEY] [--click] [--tls] [--golang] [--attach ATTACH] [--cmd CMD]
[--rmfile RMFILE] [--reportcrash REPORTCRASH] [--memdump] [--nomemdump] [-z [MALLOC]] [-zz] [-d]

optional arguments:
-h, --help show this help message and exit
-l, --local target will be executed locally
-k, --client target a network client
-s, --server target a network server
-c CMDLINE, --cmdline CMDLINE
target command line
-i INPUTS, --inputs INPUTS
input directory or file
-n ITERATIONS, --iterations ITERATIONS
number of fuzzing iterations (default: 1)
-x MAXTIME, --maxtime MAXTIME
timeout for the run (default: 1)
--mutator MUTATOR, --mutator MUTATOR
timeout for the run (default: 0=random)
-a ADDRESS, --address ADDRESS
server address in the ip:port format
-o CRASHDIR, --crashdir CRASHDIR
specify the directory to output crashes (default: crashes)
-t TEMPDIR, --tempdir TEMPDIR
specify the directory to output runtime fuzzing artifacts (default: OS tmp + run dir)
-f FUZZFILE, --fuzzfile FUZZFILE
specify the path and filename to place the fuzzed file (default: OS tmp + run dir + fuzz_random.ext)
-m MINFILE, --minfile MINFILE
specify a crashing file to generate a minimized version of it (bonus: may also find variant bugs)
-mm SUPERMIN, --supe rmin SUPERMIN
loops minimize to grind on until no more bytes can be removed

___________________________
@hacking_Attack
@Hacking_Video

-r REPROFILE, --reprofile REPROFILE
specify a crashing file or directory to replay on the target
-e, --reuse enable second round fuzzing where any crashes found are reused as inputs
-p, --multibin use multiple requests or responses as inputs for fuzzing simple binary network sessions
-pp, --multistr use multiple requests or responses within input for fuzzing simple string-based network sessions
-u, --insulate only execute the target once and inside a debugger (eg. interactive clients)
--nofuzz, --nofuzz send input as-is without mutation (useful for debugging)
--key KEY, --key KEY send a particular key every iteration for interactive targets (eg. F5 for refresh)
--click, --click click the mouse (eg. position the cursor over target button to click beforehand)
--tl s, --tls enable TLS for network fuzzing
--golang, --golang enable fuzzing of Golang binaries
--attach ATTACH, --attach ATTACH
attach to a local server process name (mac only)
--cmd CMD, --cmd CMD execute this command after each fuzzing iteration (eg. umount /Volumes/test.dir)
--rmfile RMFILE, --rmfile RMFILE
remove this file after every fuzzing iteration (eg. target won't overwrite output file)
--reportcrash REPORTCRASH, --reportcrash REPORTCRASH
use ReportCrash to help catch crashes for a specified process name (mac only)
--memdump, --memdump enable memory dumps (win32)
--nomemdump, --nomemdump
disable memory dumps (win32)
-z [MALLOC], --malloc [MALLOC]
enable malloc debug helpers (free bugs, but perf cost)
-zz, --nomalloc disable malloc debug helpers (eg. pageheap)
-d, --debug Turn on debug statements
trophies Litefuzz has fuzzed crashes out of various software packages such as... antiword AppleScript (OS X) ArangoDB VelocyPack Avast authenticode-parser Avast RetDec BBC Audio Waveform ColorSync (OS X) Dynamsoft BarcodeReader eot2ttf evernote2md faad2 Facebook's Origami Studio FontForge ForestDB Gifsicle GPUJPEG GPAC Multimedia Framework Google Draco GoPro GPR GtkRadiant IIPImage Server John The Ripper Kyoto Cabinet latex2rtf libMeshb libembroidery libsndfile Lion Vector Graphics (lvg) L-SMASH MindNode minimp4 MiniWeb Server MLpack Nvidia Data Center GPU Manager Numbers (OS X) OpenJPEG OpenOrienteering Mapper OSM Express Pages (OS X) PBRT-Parser Pixar USD Remote Apple Events (OS X) Samsung rlottie Samsung ThorVG Shoutcast Server Silo syslog (OS X) Tencent NCNN TinyXML2 UEFITool Ulfius Web Framework zlib FAQ how did this project come about? Fuzzing is fun! And it's nice to do projects which take a contrarian type of view that fuzzers don't always have to follow the modern or popular approaches to get to the end goal of finding bugs. Whether you're close to bare metal, getting code coverage across all paths or simply optimizing on the fast and flexible, the fundamental "invalidating assumptions" way of doing things, etc. However it manifests, enjoy it. is this project actively maintained? Please do not expect active support or maintenance on the project. Feel free to fork it to add new features or fix bugs, etc. Perhaps even do a PR for smaller things, although please do no have no expectations for responses or troubleshooting. It is not intended for development on this repo to be active. how do you know the fuzzer is working well and did you measure it against others? The purpose of Litefuzz is to find bugs across platforms. And it does. So, honestly the ability to measure it against fuzzerX or fuzzerY just didn't make the cut. Certain trade-offs were made and acknowledged at inception, see the #intro (https://github.com/sec-tools/litefuzz/blob/main/README.md#intro) for more details. what would you change if you were to re-write it today? It works

___________________________
@hacking_Attack
@Hacking_Video

pretty well as it is and has been tested on a ton of different targets and scenarios. That being said, it could benefit standardizing on a more modular-based and plugin system where switching between targets and platforms didn't require as many additional checks in the operations side of the code, etc. Of course having more formal tests and a deployment system that would test it across supporting operating systems would create an environment that easier to work across when making changes to core functions. It grew from a small yet amibitious project into something a little bigger pretty quickly. how stable is litefuzz? The command line, GUI, network fuzzing (mostly on Linux and Mac), minimization, etc has been tested pretty thoroughly and should be pretty solid overall. Some of the more exotic features such as insulated network GUI fuzzing, ReportCrash support for Mac and some other niche features should be considered experimental. are there unsupported scenarios for litefuzz? A few of them, yes. But most are either uncommon scenarios that are buggy, required more time and research to "get right" or just don't quite work for platform related reasons. Many of them are explicitly exit with an "unsupported" message when you try to run it with such options and some caveats have been mentioned in the sections above when describing various features. Some of the more nuanced ones include repro mode on insulated apps isn't supported and also there's been limited testing on Mac apps using the insulate feature, Pyautogui seems to work fine on Linux and Windows but on Mac it didn't prove very reliable so consider it functionally unsupported and client fuzzing on Windows can be a little less reliable than other modes on other platforms. There may be some edge cases here and there, but the most common local and network fuzzing scenarios have been tested and are working. Ah, these are joys of writing cross-platform tooling: rewarding, but it's hard to make everything work great all the time. Overall, fuzzing on Linux/Mac seems to be more stable and support more features overall, especially as it's had much more testing of network fuzzing than on the Windows platform, but an effort was made for at least the basics to be available on Win32 with a couple extras. Feel free to fork this fuzzer and make such improvements, support the currently unsupported, etc or PRs for more minor but useful stuff. what guarentees are given for this project or it's code? Absolutely none. But it's pretty fun to fuzz and watch it hand you bugs. author / references Jeremy Brown (https://github.com/sec-tools/litefuzz/blob/main/jbrown3264%5BNOSPAM%5Dgmail) Slide deck for macOS Fuzzing (https://www.slideshare.net/JeremyBrown37/summer-of-fuzz-macos)

Download Litefuzz (https://github.com/sec-tools/litefuzz)

___________________________
@hacking_Attack
@Hacking_Video

Hacking on Medium
Hacking the International Order

by Dwayne Phillips

Continue reading on Medium »

___________________________
@hacking_Attack
@Hacking_Video

Hacking on Medium
Treasure Exploit returns stolen ‘Smol Brains’ NFTs to users — WITHCRYPTO

https://cdn-images-1.medium.com/max/1024/0*zlPNyaIM8RAr1zDC.jpg
Following positive developments, prices of Treasure’s native MAGIC token rebounded after falling by about 40% early in the Asian trading…

Continue reading on Medium »

___________________________
@hacking_Attack
@Hacking_Video

Hacking on Medium
National Safety Day — A Step Towards Safe Payments

https://cdn-images-1.medium.com/max/1920/1*3BBsZm-nWKZowo-x3hPA3w.png
Safety is the new keyword which is in the news these days. With revolution and development going hand in hand. The time has come when the…

Continue reading on Medium »

___________________________
@hacking_Attack
@Hacking_Video

KitPloit - PenTest Tools!
Litefuzz - A Multi-Platform Fuzzer For Poking At Userland Binaries And Servers

https://blogger.googleusercontent.com/img/a/AVvXsEjy4PMTSmDGQkRvHUAKHJniNaTSQkwXGRcY0gXSh7HpHCTMKkuOiG3olP8_6fsSqe009iLaTcc_vIkF2YARc7c-EpnnpRSszEQJpfLnMT2godGIeFylIeGiBiuZSiB1BGpb_naqEnYoWQa5DE62p90_MBZ5dXstvU5kAhnRASsL9rEtxH2HBMp6Aapv=w586-h640 Litefuzz is meant to serve a purpose: fuzz and triage on all the major platforms, support both CLI/GUI apps, network clients and servers in order to find security-related bugs. It simplifies the process and makes it easy to discover security bugs in many different targets, across platforms, while just making a few honest trade-offs.
It isn't built for speed, scalability or meant to win any prizes in academia. It applies simple techniques at various angles to yield results. For console-based file fuzzing, you should probably just use AFL. It has superior performance, instrumention capabilities (and faster non-instrumented execs), scale and can make freakin' jpegs out of thin air. For networking fuzzing, the mutiny fuzzer also works well if you have PCAPs to replay and frizzer looks promising as well. But if you want to give this one a try, it can fuzz those kinds of targets across platforms with just a single tool.

./ and give your target... a lite fuzz.

completed (1000) iterations with (3) unique crashes and 127 dups >> check crashes/latex2rtf for more details">$ sudo apt install latex2rtf

$ ./litefuzz.py -l -c "latex2rtf FUZZ" -i input/tex -o crashes/latex2rtf -n 1000 -z
--========================--
--======| litefuzz |======--
--========================--

[STATS]
run id: 3516
cmdline: latex2rtf FUZZ
crash dir: crashes/latex2rtf
input dir: input/tex
inputs: 1
iterations: 1000
mutator: random(mutators)

@ 1000/1000 (3 crashes, 127 duplicates, ~0:00:00 remaining)

[RESULTS]
> completed (1000) iterations with (3) unique crashes and 127 dups
>> check crashes/latex2rtf for more details

This is a simple local target which AFL++ is perfectly capable of handling and just quickly given as an example. Litefuzz was designed to do much more in the way of network and GUI fuzzing which you'll see once you dive in. whyYes, another fuzzer and one that doesn't track all that well with the current trends and conventions. Trade-offs were made to address certain requirements. These requirements being a fuzzer that works by default on multiple platforms, fuzzes both local and network targets and is very easy to use. Not trying to convince anybody of anything, but let's provide some context. Some targets require a lot of effort to integrate fuzzers such as AFL into the build chain. This is not a problem as this fuzzer does not require instrumentation, sacraficing the precise coverage gained by instrumentation for ease and portability. AFL also doesn't support network fuzzing out of the box, and while there are projects based on it that do, they are far from straightforward to use and usually require more code modifications and harnesses to work (similar story with Libfuzzer). It doesn't do parallel fuzzing, nor support anything like the blazing speed improvments that persistent mode can provide, so it cannot scale anywhere close to what fuzzers with such capabilities. Again, this is not a state-of-the-art fuzzer. But it doesn't require source code, properly up a build or certain OS features. It can even fuzz some network client GUIs and interactive apps. It lives off the land in a lot of ways and many of the features such as mutators and minimization were just written from scratch.

It was designed to "just work" and effort has been put into automating the setup and installation for the few dependencies it needs. This fuzzer was written to serve a purpose, to provide value in a lot of different target scenarios and environm[...]

___________________________
@hacking_Attack
@Hacking_Video

ents and most importantly and for what all fuzzers should ultimately be judged on: the ability to find bugs. And it does find bugs. It doesn't presume there is target source code, so it can cover closed source software fairly well. It can run as part of automation with little modification, but is geared towards being fun to use for vulnerability researchers. It is however more helpful to think of it as a R&D project rather than a fully-fledged product. Also, there's no complicated setup w here it's slightly broken out of the box or needs more work to get it running on modern operating systems. It's been tested working on Ubuntu Linux 20.04, Mac OS 11 and Windows 10 and comes with fully functional scripts that do just about everything for you in order to setup a ready-to-fuzz environment.

Once the setup script completes, it only takes a few minutes to get started fuzzing a ton of different targets. how it worksLitefuzz supports three different modes: local, client and server. Local means targeting local binaries, which on Linux/Mac are launched via subprocess with automatic GDB and LLDB triage support respectively on crashes and via WinAppDbg on Windows. Crashes are written to a local crash directory and sorted by fault type, such as read/write AVs or SIGABRT/SIGSEGV along with the file hashes. All unique crashes are triaged as it fuzzes and this data along with target output (as available) is also captured and placed as artifacts in the same directory. It's also possible to replay crashes with --replayand providing the crashing file. In localclient mode, the input directory should contain a server greeting, response or otherwise data that a client would expect when connecting to a server. As of now only one "shot" is implementated for network fuz zing with no complex session support. The client is launched via command line and debugged the same as when file fuzzing. A listener is setup to support this scenario, yes its a slow and borderline manual labor but it works. If a crash is detected, it is replayed in gdb to get the triage details. In remoteclient mode, this works the same expect for no local debugging / crash triage. In local server mode, it's similar to local client mode and for remoteserver mode it just connects to a specified target and send mutated sample client data that the user specifies as inputs, but only a simple "can we still connect, if not then it probably crashed on the last one" triage is provided.

There are a few mutation functions written from scratch which mostly do random mutations with a random selection of inputs specified by the -iflag. For file fuzzing, just select local mode and pass it the target command line with FUZZ denoting where the app expects the filename to parse, eg. tcpdump -r FUZZalong with an input directory of "good files" to mutate. For network client fuzzing, it's similar to local fuzzing, but also provide connection specifics via -a. And if you want to fuzz servers, do server mode and provide a protocol://address:portjust like for clients.

It fuzzes as fast as the target can consume the data and exit, such as the case for most CLI applications or for as long as you've determined it needs before the local execution or network connection times out, which can be much slower. No fancy exec or kernel tricks here. But of course if you write a harness that parses input and exits quickly, covering a specific part of the target, that helps too. But at that point, if you can get that close to the target, you're probably better off using persistant mode or similar features that other fuzzers can offer.

In short... what it does* runs on linux, windows and mac and supports py2/py3
* fuzzes CLI/GUI binaries that read from files/stdin
* fuzzes network clients and servers, open source or proprietary, available to debug locally or remote
* diffs, mini[...]

___________________________
@hacking_Attack
@Hacking_Video

mization, replay, sorting and auto-triaging of crashes
* misc stuff like TLS support, golang binary fuzzing and some extras for Mac
* mutates input with various built-in mutators + pyradamsa (Linux) what it doesn't do* native instrumentation
* scale with concurrent jobs
* complex session fuzzing
* remote client and server monitoring (only basic checks eg. connect) supportPrimarily tested on Ubuntu Linux 20.04 (lightly tested on 21.04), Windows 10 and Mac OS 11. The fuzzer and setup scripts may work on slightly older or newer versions of these operating systems as well, but the majority of research, testing and development occurred in these environments. Python3 is supported and an effort was made to make the code compatiable with Python2 as well as it's necessary for fuzzing on Windows via WinAppDbg. Platform testing primarily occured on Intel-based hardware, but things seem to mostly work on Apple's M1 platform too (notable exceptions being on Linux the exploitable plugin for GDB probably isn't supported, nor is Pyradamsa). There are also setup scripts in setup/ to automate most or all of the tasks and depencency installation. It can generally fuzz native binaries on each platform, wh ich are often compiled in C/C++, but it also catch crashes for Golang binaries as well (experimental). python versionsPython3 is supported for Linux and Mac while Python2 is required for Windows.

Why Py3 for Linux and Mac? Pyautogui, Pyradamsa (Linux only), better socket support on Mac.

Why Py2 for Windows? Winappdbg requires Py2. linuxGDB for debugging and exploitable for crash triage. If it's OSS, you can build and instrument the target with sanitizers and such, otherwise there's some memory debuggers we can just load at runtime.

This installation along with the python dependencies and other helpful stuff has been automated with setup/linux.sh. Recommended OS is Ubuntu 20.04 as that is where the majority of testing occurred. macInstead of gdb, we use lldb for debugging on OS X as it's included with the XCode command line tools. Being an admin or in the developer group should let you use lldb, but this behavior may differ across environments and versions and you may need to run it with sudo privileges if all else fails.

The one thing you'll manually need to do is turn off SIP (in recovery, via cmd+R or use vmware fusion hacks). Otherwise, auto-triage will fail when fuzzing on Tim Apple's OS.

Almost all of the setup has been automated with the setup/mac.sh script, so you can just run it for a quick start. windowsWinAppDbg is used for debugging on Windows with the slight caveat that stdin fuzzing isn't supported.

Like the automated setups for the other operating systems, chocolatey helps to automate package installation on windows. Run setup/windows.bat in the litefuzz root directory as Administrator to automate the installations. It will install debugging tools and other dependencies to make things run smoothly. targetsThis is a list of the types of targets that have been tested and are generally supported.

*
Local CLI/GUI apps that parse file formats or stdin

* debug support

*
Local CLI/GUI network client that parses server responses

* debug support for CLIs
* limited debug support for GUIs

*
Local CLI network server that parses client requests

* debug support (caveat: must able to run as a standalone executable, otherwise can be treated as remote)

*
Local GUI network server that parses client requests

* theoretically supported, untested

*
Remote CLI/GUI network client that parses server responses

* no debug support

*
Remote CLI/GUI network server that parses client requests

* no debug support
* exception being on Mac and using attachor reportcrashfeatures
Again, the fuzzer can run on and support local apps, clients and servers on Linux, Mac and Windows and of course can fuzz remote stu[...]

___________________________
@hacking_Attack
@Hacking_Video

ff independent of the target platform. triage*
Local CLI/GUI apps that parse file formats or stdin

* run app, catch signals, repro by running it again inside a debugger with the crasher

*
Local CLI/GUI network client that parses server responses

* run app, catch signals, repro by running it again inside a debugger with the crasher

*
Local GUI/CLI network server that parses client requests

* run app in debugger, catch signals, repro by running it again inside a debugger with the crasher

*
Remote CLI/GUI network client that parses server responses

* no visiblity, collect crashes from the remote side
* can manually write supporting scripts to aid in triage

*
Remote CLI/GUI network server that parses client requests

* no visiblity, collect crashes from the remote side
* can manually write supporting scripts to aid in triage
* exception on Mac are the attachand reportcrashoptions, which can be used to enable some triage capabilities getting startedMost of the setup across platforms has been automated with the scripts in the setup directory. Simply run those from the litefuzz root and it should save you a lot of time and help enable some of what's needed for automated deployments. It's useful to use a VM to setup a clean OS and fuzzing environment as among other things its snapshot capabilities come in handy.

See INSTALL.md for details. testsunit testsThere are a few simple unit and functional tests to get some coverage for Litefuzz, but it is not meant to be complete. py2> pytest
py3> python3 -m pytest This will run pytest for test_litefuzz.pyin the main directory and provide PASS/FAIL results once the test run is finished. crashing app testsA few examples of buggy apps for testing crash and triage capabilities on the different platforms can be found in the testfolder.

* (a) null pointer dereference
* (b) divide-by-zero
* (c) heap overflow
* (d-gui) format string bug in a GUI
* (e) buffer overflow in client
* (f) buffer overflow in server

They are automatically built during setup and you can run them on the command line, in a debugger or use them to test as fuzzing targets. If running on Windows command line, check Event Viewer -> Windows Logs -> Applicationto see crashes. optionsThere are a ton of different options and features to take advantage of various target scenarios. The following is a brief explanation and some examples to help understand how to use them. crash directory-olets you specify a crash directory other than the default, which is the crashes/ in the local path. One can use this to manage crash folders for several concurrent fuzzing runs for different apps at the same time. insulate mode-uinsulates the target application from the normal fuzzing process, eg. execs or sending packets over and over and checking for crashes. Instead, this mode was made for interactive client applications, eg. Postman where you can script inside the application to repeat connections for client fuzzing. The target is ran inside of a debugger, the fuzzer is paused to get the user time to click a few buttons or sets the target's config to make it run automatically, user resumes and now you are fuzzing interactive network clients. litefuzz -lk -c "/snap/postman/140/usr/share/Postman/_Postman" -i input/http_responses -a tcp://localhost:8080 -u -n 100000 -zInsulate mode + refresh can be used for interactive clients, eg. run FileZilla in a debugger, but keep hitting F5 to make it reconnect to the server for each new iteration. Also, fuzzing local CLI/GUI servers are only started and ran once inside a debugger to make the process a little more efficient. --keyalso allows you to send keys while fuzzing interactive targets, such as fuzzing FileZilla's parsing of FTP server responses by sending "refre[...]

___________________________
@hacking_Attack
@Hacking_Video

KitPloit - PenTest Tools!
Litefuzz - A Multi-Platform Fuzzer For Poking At Userland Binaries And Servers

___________________________
@hacking_Attack
@Hacking_Video

Dark Reading: Attacks/Breaches
How Retailers Can Address 'Buy Now, Pay Later' Fraud

As BNPL platforms grow in popularity, experts warn that cybercriminals could target them using synthetic identity fraud and first-party fraud.

hacking: security in practice
How does UDP Flood on webservers work?

I am very likely to have misunderstood something here, since I don't know much about web in general. But shouldn't a UDP flood only work if the victim ports, which receive the UDP traffic aren't blocking all udp data. Doesn't that mean UDP flood only works, when there's a port/service on that webservers, which allows UDP data like a videochat or sth. In conclusion: when there's a webserver that doesn't use UDP at all, isn't it immune to UDP flood attacks?

Probably a lot wrong here, so please go soft on me >~

submitted by /u/LarryTheSnobster
[link] [comments]

___________________________
@hacking_Attack
@Hacking_Video

Kali Linux Tutorials
Wifi-Framework : For Creating Proof-Of-Concepts, Automated Experiments, Test Suites, Fuzzers, And More…

Wifi-Framework is a framework to more easily perform Wi-Fi experiments. It can be used to create fuzzers, implement new attacks, create proof-of-concepts to test for vulnerabilities, automate experiments, implement test suites, and so on.

The main advantage of the framework is that it allows you to reuse Wi-Fi functionality of Linux to more easily implement attacks and/or tests. For instance, the framework can connect to (protected) Wi-Fi networks for you and can broadcast beacons for you when testing clients. In general, any Wi-Fi functionality of Linux can be reused to more quickly implement attacks/tests. The framework accomplishes this by executing test cases on top of the hostap user space daemon.
https://blogger.googleusercontent.com/img/a/AVvXsEi27NzKEWwoQn_Wm7MQ2kEms5PkICD7q5ajoQtftXY4WudUUBqbIvkToXH9TUSLTEJDVa2ZNemv6bZYm6_OEzqw45lCfIZ3Bpt1qpyQDzzAvzRL-j0O9RSJlJTUuaUFuran8f5TQptPNUI5E2lyM_x3MV4dJTP73PYKkeRopUeYVQmMkPsJCPI-uLpF=s1000
If you are new to performing Wi-Fi experiments on Linux it is highly recommended to first read the libwifi Linux Tutorial. When you are implementing basic Wi-Fi attacks without the need to reuse Linux functionality, then the framework provides limited advantages and you can instead consider directly implementing attacks in Scapy and optionally use the libwifi library. Usage

To use the framework:

* Install it by running ./setup.sh. See setup to know what this script does.
* Read the usage tutorial. Example

Say you want to test whether a client ever encrypts frames using an all-zero key. This can happen during a key reinstallation attack. By using the framework you do not need to reimplement all functionality of an access point, but only need to write the following test case:

class ExampleKrackZerokey(Test):
name = “example-krack-zero-key”
kind = Test.Authenticator
def init(self):
super().init([
# Replay 4-Way Handshake Message 3/4.
Action( trigger=Trigger.Connected, action=Action.Function ),
# Receive all frames and search for one encrypted with an all-zero key.
Action( trigger=Trigger.NoTrigger, action=Action.Receive ),
# When we receive such a frame, we can terminate the test.
Action( trigger=Trigger.Received, action=Action.Terminate )
])
def resend(self, station):
# Resend 4-Way Handshake Message 3/4.
station.wpaspy_command(“RESEND_M3 ” + station.clientmac )
def receive(self, station, frame):
if frame[Dot11].addr2 != station.clientmac or not frame.haslayer(Dot11CCMP):
return False
# Check if CCMP-encrypted frame can be decrypted using an all-zero key
plaintext = decrypt_ccmp(frame.getlayer(Dot11), tk=b”\x00″*16)
if plaintext is None: return False
# We received a valid plaintext frame!
log(STATUS,’Client encrypted a frame with an all-zero key!’, color=”green”)
return True

The above test case will create an access point that clients can connect to. After the client connects, a new 3rd message in the 4-way handshake will be sent to the client. A vulnerable client will then start using an all-zero encryption key, which the test case automatically detects.

You can run the above test case using simulated Wi-Fi radios as follows:

./setup/setup-hwsim.sh 4
source setup/venv/bin/activate
./run.py wlan1 example-krack-zero-key

You can connect to the created access point to test it (network testnetworkwith password passphrase):

./hostap.py wlan2

By changing the network configuration this AP can easily be configured to use WPA2 or WPA3 and/or can be configured to use enterprise authentication, without making any changes to the test case that we wrote! Additional benefits of using the framework in this example are:

* No need to manually broadcast beacons
* The authentication and association stage [...]

___________________________
@hacking_Attack
@Hacking_Video

is handled by the framework
* The WPA2 and/or WPA3 handshake is handled by the framework
* Injected packets will be automatically retransmitted by the Linux kernel
* Packets sent towards the AP will be acknowledged
* Sleep mode of the client is automatically handled by the kernel
* … Download

___________________________
@hacking_Attack
@Hacking_Video

Weakly Typed SQL Injection

Programming languages come in two categories: Hard/Strong Typed Soft/Weak TypedContinue reading on Medium »
Read more...