hacking: security in practice
As the Tanks Rolled into Ukraine, So Did Malware. Then Microsoft Entered the War.

https://external-preview.redd.it/qvqaeHFXrmQ8mr5oNaezZdsOWCURHy-vvOnchBRrLtM.jpg?width=640&crop=smart&auto=webp&s=debdc14a33daa60eddc3b945d3defb4697531263 submitted by /u/ivyguy507
[link] [comments]

___________________________
@hacking_Attack
@Hacking_Video

hacking: security in practice
Cyber Security Documents

Hi everyone,

I'm looking for a SLA template for penertration testing an vulnerability scanning. Please advise where I can this, I would really appreciate it. Thank you.

submitted by /u/messi1_0-
[link] [comments]

___________________________
@hacking_Attack
@Hacking_Video

hacking: security in practice
Hacker makes life miserable for top Mumbai executive

https://www.indiatoday.in/india/story/hacker-makes-life-miserable-for-top-mumbai-executive-1919796-2022-03-02

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

___________________________
@hacking_Attack
@Hacking_Video

Kali Linux Tutorials
RAUDI : A Repo To Automatically Generate And Keep Updated A Series Of Docker Images

RAUDI (Regularly and Automatically Updated Docker Images) automatically generates and keep updated a series of Docker Images through GitHub Actions for tools that are not provided by the developers.

What is RAUDI

RAUDI is what will save you from creating and managing a lot of Docker Images manually. Every time a software is updated you need to update the Docker Image if you want to use the latest features, the dependencies are not working anymore.

This is messy and time-consuming.

Don’t worry anymore, we got you covered.

You may either fork this repo and use the GitHub Workflow yourself or use it locally (and manage its execution the way you want). Fork

If you want to fork this repo you also have to set up some secrets to be able to push your images on your personal Docker Hub account. Two GitHub secrets must be set:

* DOCKER_USER: Your Docker Hub Username;
* DOCKER_API_TOKEN: Your Docker Hub Password or API Token.

After setting those secrets you have to edit the organization variable set in the tools/main.py file since it is configured to push on the Docker Hub for SecSI.

That’s all guys: go to Action, enable it for your forked repo, wait until midnight, and the Workflow will do the heavy work! Setup

This repo can also be executed locally. The requirements to be met are the following:

* Python 3.x
* Docker (with BuildX)

Here is the documentation for working with BuildX: https://docs.docker.com/buildx/working-with-buildx/

The setup phase is pretty straightforward, you just need the following commands:

git clone https://github.com/cybersecsi/RAUDI
cd RAUDI
pip install -r requirements.txt

You’re ready to go! Test

To run the test you need to install pytestwith the command pip install pytest(it is not in requirements.txtsince it is needed only for testing purposes) and then you may run:

pytest -s

or

python -m pytest -s

to run the tests. Local Usage

RAUDI can build and push all the tools that are put into the tools directory. There are different options that can be used when running it. Before using it locally you should create a .env file (you can just copy the .env.sample file) and add your GitHub Personal Access Token to avoid Rate Limiting. For unauthenticated users GitHub allows up to 60 requests per hour, while authenticated users are allowed up to 15.000 requests per hour. For this reason we advice you to add it! You can also create a personal access token without any scope since anything we do is read some info for every GitHub repo. Execution Modes Normal Execution

In this mode RAUDI tries to build all the tools if needed. The command to run it is simply:

python3 ./raudi.py –all

Single Build

In this mode RAUDI tries to build only the specified tool. The command in this case is:

python3 ./raudi.py –single

tool_name MUST be the name of the directory inside the tools folder. Test tool

Since the tests parameter has been added to the configuration structure of the tool is can be helpful to test if the inserted commands do return a 0 status code. The command to test a specific tool is:

python3 ./raudi.py –test

tool_name MUST be the name of the directory inside the tools folder. Show tools

If you want to know the available tools you can run this command:

python3 ./raudi.py –list

Bootstrap tool

If you want to quickly add a new tool folder starting from one of the available templates you can run this command:

python3 ./raudi.py –bootstrap

Options
OptionDescriptionDefault Value–pushWhether automatically push to Docker HubFalse–remoteWhether check against Docker Hub instead of local Docker before buildFalse–forceWhether build or not if an image with the same tagname has been foundFalse Available Tools

This [...]

___________________________
@hacking_Attack
@Hacking_Video

is the current list of tools that have been added. Those are all tools that do not have an official Docker Image provided by the developer:
NameDocker ImageSource3proxysecsi/3proxyhttps://github.com/3proxy/3proxyAltdnssecsi/altdnshttps://github.com/infosec-au/altdnsApktoolsecsi/apktoolhttps://github.com/iBotPeaches/ApktoolArjunsecsi/arjunhttps://github.com/s0md3v/Arjunbfacsecsi/bfachttps://github.com/mazen160/bfacCloudFailsecsi/cloudfailhttps://github.com/m0rtem/CloudFailCMSeeKsecsi/cmseekhttps://github.com/Tuhinshubhra/CMSeeKCrowbarsecsi/crowbarhttps://github.com/galkan/crowbarDalfoxsecsi/dalfoxhttps://github.com/hahwul/dalfoxdatasploitsecsi/datasploithttps://github.com/DataSploit/datasploitdex2jarsecsi/dex2jarhttps://github.com/pxb1988/dex2jardirbsecsi/dirbhttp://dirb.sourceforge.net/dirhuntsecsi/dirhunthttps://github.com/Nekmo/dirhuntdirsearchsecsi/dirsearchhttps://github.com/maurosoria/dirsearchdnscansecsi/dnscanhttps://github.com/rbsec/dnscanDorks Eyesecsi/dorks-eyehttps://github.com/BullsEye0/dorks-eyedvcs-rippersecsi/dvcs-ripperhttps://github.com/kost/dvcs-ripperExifToolsecsi/exiftoolhttps://github.com/exiftool/exiftoolEyeWitnesssecsi/eyewitnesshttps://github.com/FortyNorthSecurity/EyeWitnessfast-reconsecsi/fast-reconhttps://github.com/DanMcInerney/fast-reconffufsecsi/ffufhttps://github.com/ffuf/ffuffiercesecsi/fiercehttps://github.com/mschwager/fierceFindsploitsecsi/findsploithttps://github.com/1N3/FindsploitGetJSsecsi/getjshttps://github.com/003random/getJSGitrobsecsi/gitrobhttps://github.com/michenriksen/gitrobGitToolssecsi/gittoolshttps://github.com/internetwache/GitToolgobustersecsi/gobusterhttps://github.com/OJ/gobusterGoogD0rkersecsi/googd0rkerhttps://github.com/ZephrFish/GoogD0rkerGoSpidersecsi/gospiderhttps://github.com/jaeles-project/gospiderGround controlsecsi/ground-controlhttps://github.com/jobertabma/ground-controlHakrawlersecsi/hakrawlerhttps://github.com/hakluke/hakrawlerhakrevdnssecsi/hakrevdnshttps://github.com/hakluke/hakrevdnshashIDsecsi/hashidhttps://github.com/psypanda/hashIDhttprobesecsi/httprobehttps://github.com/tomnomnom/httprobehydrasecsi/hydrahttps://github.com/vanhauser-thc/thc-hydraimpacketsecsi/impackethttps://github.com/SecureAuthCorp/impacketJoomScansecsi/joomscanhttps://github.com/OWASP/joomscanThe JSON Web Token Toolkitsecsi/jwt_toolhttps://github.com/ticarpi/jwt_toolknocksecsi/knockpyhttps://github.com/guelfoweb/knockLFI Suitesecsi/lfisuitehttps://github.com/D35m0nd142/LFISuiteLinkFindersecsi/linkfinderhttps://github.com/GerbenJavado/LinkFinderMASSCANsecsi/masscanhttps://github.com/robertdavidgraham/masscanMassDNSsecsi/massdnshttps://github.com/blechschmidt/massdnsMemcrashed DDoS Exploitsecsi/memcrashedhttps://github.com/649/Memcrashed-DDoS-ExploitNetifysecsi/netifydhttps://gitlab.com/netify.ai/public/netify-agentniktosecsi/niktohttps://github.com/sullo/niktonmapsecsi/nmaphttps://github.com/nmap/nmapoxml_xxesecsi/oxml_xxehttps://github.com/BuffaloWill/oxml_xxePagodosecsi/pagodohttps://github.com/opsdisk/pagodophotonsecsi/photonhttps://github.com/s0md3v/PhotonPivotSuitesecsi/pivotsuitehttps://github.com/RedTeamOperations/PivotSuitepsalmsecsi/psalmhttps://github.com/vimeo/psalmpureDNSsecsi/purednshttps://github.com/d3mondev/purednsRace The Websecsi/race-the-webhttps://github.com/TheHackerDev/race-the-webRestfulHarvestsecsi/restfulharvesthttps://github.com/laramies/theHarvesterRetire.jssecsi/retirehttps://github.com/RetireJS/retire.jsRouterSploitsecsi/routersploithttps://github.com/threat9/routersploitSandcastlesecsi/sandcastlehttps://github.com/0xSearches/sandcastlescanlesssecsi/scanlesshttps://github.com/vesche/scanlessseclistssecsi/seclistshttps://github.com/danielmiessler/SecListsspyse.pysecsi/spysepyhttps://github.com/zeropwn/spyse.pysqlmapsecsi/sqlmaphttps://github.com/sqlmapproject/sqlmapspidysecsi/spidyhttps://github.com/rivermont/spidyStrikersecsi/strikerhttps://github.com/s0md3v/StrikerSubfindersecsi/subfinderhttps://github.com/projectdiscovery/subfinderSubjacksecsi/[...]

___________________________
@hacking_Attack
@Hacking_Video

Kali Linux Tutorials
RAUDI : A Repo To Automatically Generate And Keep Updated A Series Of Docker Images

___________________________
@hacking_Attack
@Hacking_Video

Litefuzz - A Multi-Platform Fuzzer For Poking At Userland Binaries And Servers
http://www.kitploit.com/2022/03/litefuzz-multi-platform-fuzzer-for.html

___________________________
@hacking_Attack
@Hacking_Video

kex_input_kexinit: discard proposal: string is too large
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: string is too large

... and others like

ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: unknown or unsupported key type

ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Host key verification failed.

Bad packet length 1869636974.
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: message authentication code incorrect
-pp asks the fuzzer to check inputs for line breaks and if detected, treat those as multiple requests / responses. This is useful for simple network protocol fuzzing for mostly string-based protocol implementations, eg. ftp clients. cat input/ftp/test
220 ProFTPD Server (Debian) [::ffff:localhost]
331 Password required for user
230 User user logged in
215 UNIX Type: L8
221 Goodbye
The fuzzer breaks each line into it's own FTP response to try and fuzz a client's handling of a session. There's no guarentee, however, that a client will "behave" or act in ways that don't allow a session to complete properly, so some trial and error + fine tuning for session test cases while running Wireshark can be helpful for understanding the differences in interaction between targets. litefuzz -lk -c "ftp localhost 2121" -a tcp://localhost:2121 -i input/ftp -o crashes/ftp -n 100000 -pp -z This can also be combined with -u for insulating GUI network targets like FileZilla. litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp.resp -n 100000 -u -pp -z glibc attaching to a process If the target spawns a new process on connection, one can specify the name of a process (or pid) to attach to after a connection has been established to the server. This is handy in cases where eg. launchd is listening on a port and only launches the handling process once a client is connected. This is one feature that sort of blurs the line between local and remote fuzzing, as technically the fuzzer is in remote mode, yet we specify the target address as localhost and ask it to attach to a process. ./litefuzz.py -s -a tcp://localhost:8080 -i input/shareserv -p --attach ShareServ -x 1 -n 100000 note: currently this feature is only supported on Mac (LLDB) and for network fuzzing, although if implemented it should work fine for Linux (GDB) too. crash artifacts When a crash is encountered during fuzzing, it is replayed in a debugger to produce debug artifacts and bucketing information. The information varies from platform to platform, but generally the a text file is produced with a backtrace, register information, !exploitable type stuff (where available) and other basic information. Memory dumps can be enabled on Windows by passing the --memdump or disabled with --nomemdump similar to how malloc debuggers are controlled via -z and -zz respectively. If enabled, the dump will also be loaded in the console debugger (cdbg) and !analyze -v crash analysis output is captured within an additional memory dump crash analysis log. Winappdbg already has !exploitable type analysis that we get in the initial crash analysis, so we just do !analyze here. litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --memdump or to disable memory dumps for an application litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --nomemdump In addition to auto-crash triage, binary/string diffs (as appropriate) and target stdout (platform / target dependent) is also produced and repro files of course. For local fuzzing, artifacts generally include diffs, stdout (linux/mac only), repro file and the crash log and information file. $ ls crashes/latex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diff
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diffs

___________________________
@hacking_Attack
@Hacking_Video

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