Radamsa - A General-Purpose Fuzzer

Radamsa is a test case generator for robustness testing, a.k.a. a fuzzer. It is typically used to test how well a program can withstand malformed and potentially malicious inputs. It works by reading sample files of valid data and generating interestringly different outputs from them. The main selling points of radamsa are that it has already found a slew of bugs in programs that actually matter, it is easily scriptable and, easy to get up and running.

Nutshell:

 $ # please please please fuzz your programs. here is one way to get data for it:
 $ sudo apt-get install gcc make git wget
 $ git clone https://gitlab.com/akihe/radamsa.git && cd radamsa && make && sudo make install
 $ echo "HAL 9000" | radamsa

What the Fuzz

Programming is hard. All nontrivial programs have bugs in them. What's more, even the simplest typical mistakes are in some of the most widely used programming languages usually enough for attackers to gain undesired powers.

Fuzzing is one of the techniques to find such unexpected behavior from programs. The idea is simply to subject the program to various kinds of inputs and see what happens. There are two parts in this process: getting the various kinds of inputs and how to see what happens. Radamsa is a solution to the first part, and the second part is typically a short shell script. Testers usually have a more or less vague idea what should not happen, and they try to find out if this is so. This kind of testing is often referred to as negative testing, being the opposite of positive unit- or integration testing. Developers know a service should not crash, should not consume exponential amounts of memory, should not get stuck in an infinite loop, etc. Attackers know that they can probably turn certain kinds of memory safety bugs into exploits, so they fuzz typically instrumented versions of the target programs and wait for such errors to be found. In theory, the idea is to counterprove by finding a counterexample a theorem about the program stating that for all inputs something doesn't happen.

There are many kinds of fuzzers and ways to apply them. Some trace the target program and generate test cases based on the behavior. Some need to know the format of the data and generate test cases based on that information. Radamsa is an extremely "black-box" fuzzer, because it needs no information about the program nor the format of the data. One can pair it with coverage analysis during testing to likely improve the quality of the sample set during a continuous test run, but this is not mandatory. The main goal is to first get tests running easily, and then refine the technique applied if necessary.

Radamsa is intended to be a good general purpose fuzzer for all kinds of data. The goal is to be able to find issues no matter what kind of data the program processes, whether it's xml or mp3, and conversely that not finding bugs implies that other similar tools likely won't find them either. This is accomplished by having various kinds of heuristics and change patterns, which are varied during the tests. Sometimes there is just one change, sometimes there a slew of them, sometimes there are bit flips, sometimes something more advanced and novel.

Radamsa is a side-product of OUSPG's Protos Genome Project, in which some techniques to automatically analyze and examine the structure of communication protocols were explored. A subset of one of the tools turned out to be a surprisingly effective file fuzzer. The first prototype black-box fuzzer tools mainly used regular and context-free formal languages to represent the inferred model of the data.

Requirements

Supported operating systems: * GNU/Linux * OpenBSD * FreeBSD * Mac OS X * Windows (using Cygwin)

Software requirements for building from sources: * gcc / clang * make * git * wget

Building Radamsa

 $ git clone https://gitlab.com/akihe/radamsa.git
 $ cd radamsa
 $ make
 $ sudo make install # optional, you can also just grab bin/radamsa
 $ radamsa --help

Radamsa itself is just a single binary file which has no external dependencies. You can move it where you please and remove the rest.

Fuzzing with Radamsa

This section assumes some familiarity with UNIX scripting.

Radamsa can be thought as the cat UNIX tool, which manages to break the data in often interesting ways as it flows through. It has also support for generating more than one output at a time and acting as a TCP server or client, in case such things are needed.

Use of radamsa will be demonstrated by means of small examples. We will use the bc arbitrary precision calculator as an example target program.

In the simplest case, from scripting point of view, radamsa can be used to fuzz data going through a pipe.

 $ echo "aaa" | radamsa
 aaaa

Here radamsa decided to add one 'a' to the input. Let's try that again.

 $ echo "aaa" | radamsa
 ːaaa

Now we got another result. By default radamsa will grab a random seed from /dev/urandom if it is not given a specific random state to start from, and you will generally see a different result every time it is started, though for small inputs you might see the same or the original fairly often. The random state to use can be given with the -s parameter, which is followed by a number. Using the same random state will result in the same data being generated.

 $ echo "Fuzztron 2000" | radamsa --seed 4
 Fuzztron 4294967296

This particular example was chosen because radamsa happens to choose to use a number mutator, which replaces textual numbers with something else. Programmers might recognize why for example this particular number might be an interesting one to test for.

You can generate more than one output by using the -n parameter as follows:

 $ echo "1 + (2 + (3 + 4))" | radamsa --seed 12 -n 4
 1 + (2 + (2 + (3 + 4?)
 1 + (2 + (3 +?4))
 18446744073709551615 + 4)))
 1 + (2 + (3 + 170141183460469231731687303715884105727))

There is no guarantee that all of the outputs will be unique. However, when using nontrivial samples, equal outputs tend to be extremely rare.

What we have so far can be used to for example test programs that read input from standard input, as in

 $ echo "100 * (1 + (2 / 3))" | radamsa -n 10000 | bc
 [...]
 (standard_in) 1418: illegal character: ^_
 (standard_in) 1422: syntax error
 (standard_in) 1424: syntax error
 (standard_in) 1424: memory exhausted
 [hang]

Or the compiler used to compile Radamsa:

 $ echo '((lambda (x) (+ x 1)) #x124214214)' | radamsa -n 10000 | ol
 [...]
 > What is 'ó µ'? 
 4901126677
 > $

Or to test decompression:

 $ gzip -c /bin/bash | radamsa -n 1000 | gzip -d > /dev/null

Typically however one might want separate runs for the program for each output. Basic shell scripting makes this easy. Usually we want a test script to run continuously, so we'll use an infinite loop here:

 $ gzip -c /bin/bash > sample.gz
 $ while true; do radamsa sample.gz | gzip -d > /dev/null; done

Notice that we are here giving the sample as a file instead of running Radamsa in a pipe. Like cat Radamsa will by default write the output to stdout, but unlike cat when given more than one file it will usually use only one or a few of them to create one output. This test will go about throwing fuzzed data against gzip, but doesn't care what happens then. One simple way to find out if something bad happened to a (simple single-threaded) program is to check whether the exit value is greater than 127, which would indicate a fatal program termination. This can be done for example as follows:

 $ gzip -c /bin/bash > sample.gz
 $ while true
 do
   radamsa sample.gz > fuzzed.gz
   gzip -dc fuzzed.gz > /dev/null
   test $? -gt 127 && break
 done

This will run for as long as it takes to crash gzip, which hopefully is no longer even possible, and the fuzzed.gz can be used to check the issue if the script has stopped. We have found a few such cases, the last one of which took about 3 months to find, but all of them have as usual been filed as bugs and have been promptly fixed by the upstream.

One thing to note is that since most of the outputs are based on data in the given samples (standard input or files given at command line) it is usually a good idea to try to find good samples, and preferably more than one of them. In a more real-world test script radamsa will usually be used to generate more than one output at a time based on tens or thousands of samples, and the consequences of the outputs are tested mostly in parallel, often by giving each of the output on command line to the target program. We'll make a simple such script for bc, which accepts files from command line. The -o flag can be used to give a file name to which radamsa should write the output instead of standard output. If more than one output is generated, the path should have a %n in it, which will be expanded to the number of the output.

 $ echo "1 + 2" > sample-1
 $ echo "(124 % 7) ^ 1*2" > sample-2
 $ echo "sqrt((1 + length(10^4)) * 5)" > sample-3
 $ bc sample-* < /dev/null
 3
 10
 5
 $ while true
 do
   radamsa -o fuzz-%n -n 100 sample-*
   bc fuzz-* < /dev/null
   test $? -gt 127 && break
 done

This will again run up to obviously interesting times indicated by the large exit value, or up to the target program getting stuck.

In practice many programs fail in unique ways. Some common ways to catch obvious errors are to check the exit value, enable fatal signal printing in kernel and checking if something new turns up in dmesg, run a program under strace, gdb or valgrind and see if something interesting is caught, check if an error reporter process has been started after starting the program, etc.

Output Options

The examples above all either wrote to standard output or files. One can also ask radamsa to be a TCP client or server by using a special parameter to -o. The output patterns are:

Remember that you can use e.g. tcpflow to record TCP traffic to files, which can then be used as samples for radamsa.

Related Tools

A non-exhaustive list of free complementary tools:

• GDB (http://www.gnu.org/software/gdb/)
• Valgrind (http://valgrind.org/)
• AddressSanitizer (http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer)
• strace (http://sourceforge.net/projects/strace/)
• tcpflow (http://www.circlemud.org/~jelson/software/tcpflow/)

A non-exhaustive list of related free tools: * American fuzzy lop (http://lcamtuf.coredump.cx/afl/) * Zzuf (http://caca.zoy.org/wiki/zzuf) * Bunny the Fuzzer (http://code.google.com/p/bunny-the-fuzzer/) * Peach (http://peachfuzzer.com/) * Sulley (http://code.google.com/p/sulley/)

Tools which are intended to improve security are usually complementary and should be used in parallel to improve the results. Radamsa aims to be an easy-to-set-up general purpose shotgun test to expose the easiest (and often severe due to being reachable from via input streams) cracks which might be exploitable by getting the program to process malicious data. It has also turned out to be useful for catching regressions when combined with continuous automatic testing.

Some Known Results

A robustness testing tool is obviously only good only if it really can find non-trivial issues in real-world programs. Being a University-based group, we have tried to formulate some more scientific approaches to define what a 'good fuzzer' is, but real users are more likely to be interested in whether a tool has found something useful. We do not have anyone at OUSPG running tests or even developing Radamsa full-time, but we obviously do make occasional test-runs, both to assess the usefulness of the tool, and to help improve robustness of the target programs. For the test-runs we try to select programs that are mature, useful to us, widely used, and, preferably, open source and/or tend to process data from outside sources.

The list below has some CVEs we know of that have been found by using Radamsa. Some of the results are from our own test runs, and some have been kindly provided by CERT-FI from their tests and other users. As usual, please note that CVE:s should be read as 'product X is now more robust (against Y)'.

We would like to thank the Chromium project and Mozilla for analyzing, fixing and reporting further many of the above mentioned issues, CERT-FI for feedback and disclosure handling, and other users, projects and vendors who have responsibly taken care of uncovered bugs.

Thanks

The following people have contributed to the development of radamsa in code, ideas, issues or otherwise.

• Darkkey
• Branden Archer

Troubleshooting

Issues in Radamsa can be reported to the issue tracker. The tool is under development, but we are glad to get error reports even for known issues to make sure they are not forgotten.

You can also drop by at #radamsa on Freenode if you have questions or feedback.

Issues your programs should be fixed. If Radamsa finds them quickly (say, in an hour or a day) chances are that others will too.

Issues in other programs written by others should be dealt with responsibly. Even fairly simple errors can turn out to be exploitable, especially in programs written in low-level languages. In case you find something potentially severe, like an easily reproducible crash, and are unsure what to do with it, ask the vendor or project members, or your local CERT.

FAQ

Q: If I find a bug with radamsa, do I have to mention the tool?
A: No.

Q: Will you make a graphical version of radamsa?

A: No. The intention is to keep it simple and scriptable for use in automated regression tests and continuous testing.

Q: I can't install! I don't have root access on the machine!
A: You can omit the $ make install part and just run radamsa from bin/radamsa in the build directory, or copy it somewhere else and use from there.

Q: Radamsa takes several GB of memory to compile!1
A: This is most likely due to an issue with your C compiler. Use prebuilt images or try the quick build instructions in this page.

Q: Radamsa does not compile using the instructions in this page!
A: Please file an issue at https://gitlab.com/akihe/radamsa/issues/new if you don't see a similar one already filed, send email (aohelin@gmail.com) or IRC (#radamsa on freenode).

Q: I used fuzzer X and found much more bugs from program Y than Radamsa did.
A: Cool. Let me know about it (aohelin@gmail.com) and I'll try to hack something X-ish to radamsa if it's general purpose enough. It'd also be useful to get some samples which you used to check how well radamsa does, because it might be overfitting some heuristic.

Q: Can I get support for using radamsa?
A: You can send email to aohelin@gmail.com or check if some of us happen to be hanging around at #radamsa on freenode.

Q: Can I use radamsa on Windows?
A: An experimental Windows executable is now in Downloads, but we have usually not tested it properly since we rarely use Windows internally. Feel free to file an issue if something is broken.

Q: How can I install radamsa?
A: Grab a binary from downloads and run it, or $ make && sudo make install.

Q: How can I uninstall radamsa?
A: Remove the binary you grabbed from downloads, or $ sudo make uninstall.

Q: Why are many outputs generated by Radamsa equal?
A: Radamsa doesn't keep track which outputs it has already generated, but instead relies on varying mutations to keep the output varying enough. Outputs can often be the same if you give a few small samples and generate lots of outputs from them. If you do spot a case where lots of equal outputs are generated, we'd be interested in hearing about it.

Q: There are lots of command line options. Which should I use for best results?
A: The recommended use is $ radamsa -o output-%n.foo -n 100 samples/*.foo, which is also what is used internally at OUSPG. It's usually best and most future proof to let radamsa decide the details.

Q: How can I make radamsa faster?
A: Radamsa typically writes a few megabytes of output per second. If you enable only simple mutations, e.g. -m bf,bd,bi,br,bp,bei,bed,ber,sr,sd, you will get about 10x faster output.

Q: What's with the funny name?
A: It's from a scene in a Finnish children's story. You've probably never heard about it.

Q: Is this the last question?
A: Yes.

Warnings

Use of data generated by radamsa, especially when targeting buggy programs running with high privileges, can result in arbitrarily bad things to happen. A typical unexpected issue is caused by a file manager, automatic indexer or antivirus scanner trying to do something to fuzzed data before they are being tested intentionally. We have seen spontaneous reboots, system hangs, file system corruption, loss of data, and other nastiness. When in doubt, use a disposable system, throwaway profile, chroot jail, sandbox, separate user account, or an emulator.

Not safe when used as prescribed.

This product may contain faint traces of parenthesis.

PacketSpy - Powerful Network Packet Sniffing Tool Designed To Capture And Analyze Network Traffic

PacketSpy is a powerful network packet sniffing tool designed to capture and analyze network traffic. It provides a comprehensive set of features for inspecting HTTP requests and responses, viewing raw payload data, and gathering information about network devices. With PacketSpy, you can gain valuable insights into your network's communication patterns and troubleshoot network issues effectively.

Features

• Packet Capture: Capture and analyze network packets in real-time.
• HTTP Inspection: Inspect HTTP requests and responses for detailed analysis.
• Raw Payload Viewing: View raw payload data for deeper investigation.
• Device Information: Gather information about network devices, including IP addresses and MAC addresses.

Installation

git clone https://github.com/HalilDeniz/PacketSpy.git

Requirements

PacketSpy requires the following dependencies to be installed:

pip install -r requirements.txt

Getting Started

To get started with PacketSpy, use the following command-line options:

root@denizhalil:/PacketSpy# python3 packetspy.py --help                          
usage: packetspy.py [-h] [-t TARGET_IP] [-g GATEWAY_IP] [-i INTERFACE] [-tf TARGET_FIND] [--ip-forward] [-m METHOD]

options:
  -h, --help            show this help message and exit
  -t TARGET_IP, --target TARGET_IP
                        Target IP address
  -g GATEWAY_IP, --gateway GATEWAY_IP
Gateway IP address
  -i INTERFACE, --interface INTERFACE
                        Interface name
  -tf TARGET_FIND, --targetfind TARGET_FIND
                        Target IP range to find
  --ip-forward, -if     Enable packet forwarding
  -m METHOD, --method METHOD
                        Limit sniffing to a specific HTTP method

Examples

1. Device Detection

root@denizhalil:/PacketSpy# python3 packetspy.py -tf 10.0.2.0/24 -i eth0

        Device discovery
**************************************
   Ip Address       Mac Address
**************************************
    10.0.2.1      52:54:00:12:35:00
    10.0.2.2      52:54:00:12:35:00
    10.0.2.3      08:00:27:78:66:95
    10.0.2.11     08:00:27:65:96:cd
    10.0.2.12     08:00:27:2f:64:fe

2. Man-in-the-Middle Sniffing

root@denizhalil:/PacketSpy# python3 packetspy.py -t 10.0.2.11 -g 10.0.2.1 -i eth0
******************* started sniff *******************

HTTP Request:
    Method: b'POST'
    Host: b'testphp.vulnweb.com'
    Path: b'/userinfo.php'
    Source IP: 10.0.2.20
    Source MAC: 08:00:27:04:e8:82
    Protocol: HTTP
    User-Agent: b'Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0'

Raw Payload:
b'uname=admin&pass=mysecretpassword'

HTTP Response:
    Status Code: b'302'
    Content Type: b'text/html; charset=UTF-8'
--------------------------------------------------

FootNote

Https work still in progress

Contributing

Contributions are welcome! To contribute to PacketSpy, follow these steps:

1. Fork the repository.
2. Create a new branch for your feature or bug fix.
3. Make your changes and commit them.
4. Push your changes to your forked repository.
5. Open a pull request in the main repository.

Contact

If you have any questions, comments, or suggestions about PacketSpy, please feel free to contact me:

• LinkedIn: LinkedIn
• TryHackMe: TryHackMe
• Instagram: Instagram
• YouTube: YouTube
• Email: halildeniz313@gmail.com

License

PacketSpy is released under the MIT License. See LICENSE for more information.

LTESniffer - An Open-source LTE Downlink/Uplink Eavesdropper

LTESniffer is An Open-source LTE Downlink/Uplink Eavesdropper

It first decodes the Physical Downlink Control Channel (PDCCH) to obtain the Downlink Control Informations (DCIs) and Radio Network Temporary Identifiers (RNTIs) of all active users. Using decoded DCIs and RNTIs, LTESniffer further decodes the Physical Downlink Shared Channel (PDSCH) and Physical Uplink Shared Channel (PUSCH) to retrieve uplink and downlink data traffic.

LTESniffer supports an API with three functions for security applications and research. Many LTE security research assumes a passive sniffer that can capture privacy-related packets on the air. However, non of the current open-source sniffers satisfy their requirements as they cannot decode protocol packets in PDSCH and PUSCH. We developed a proof-of-concept security API that supports three tasks that were proposed by previous works: 1) Identity mapping, 2) IMSI collecting, and 3) Capability profiling.

Please refer to our paper for more details.

LTESniffer in layman's terms

LTESniffer is a tool that can capture the LTE wireless messages that are sent between a cell tower and smartphones connected to it. LTESniffer supports capturing the messages in both directions, from the tower to the smartphones, and from the smartphones back to the cell tower.

LTESniffer CANNOT DECRYPT encrypted messages between the cell tower and smartphones. It can be used for analyzing unencrypted parts of the communication between the cell tower and smartphones. For example, for encrypted messages, it can allow the user to analyze unencrypted parts, such as headers in MAC and physical layers. However, those messages sent in plaintext can be completely analyzable. For example, the broadcast messages sent by the cell tower, or the messages at the beginning of the connection are completely visible.

Ethical Consideration

The main purpose of LTESniffer is to support security and analysis research on the cellular network. Due to the collection of uplink-downlink user data, any use of LTESniffer must follow the local regulations on sniffing the LTE traffic. We are not responsible for any illegal purposes such as intentionally collecting user privacy-related information.

Features

New Update

• Supports two USRP B-series for uplink sniffing mode. Please refer to LTESniffer-multi-usrp branch and its README for more details.
• Improved the DCI 0 detected in uplink.
• Fixed some bugs.

LTESniffer is implemented on top of FALCON with the help of srsRAN library. LTESniffer supports:

• Real-time decoding LTE uplink-downlink control-data channels: PDCCH, PDSCH, PUSCH
• LTE Advanced and LTE Advanced Pro, up to 256QAM in both uplink and downlink
• DCI formats: 0, 1A, 1, 1B, 1C, 2, 2A, 2B
• Transmission modes: 1, 2, 3, 4
• FDD only
• Maximum 20 MHz base station.
• Automatically detect maximum UL/DL modulation schemes of smartphones (64QAM/256QAM on DL and 16QAM/64QAM/256QAM on UL)
• Automatically detect physical layer configuration per UE.
• LTE Security API: RNTI-TMSI mapping, IMSI collecting, UECapability Profiling.

Hardware and Software Requirement

OS Requirement

Currently, LTESniffer works stably on Ubuntu 18.04/20.04/22.04.

Hardware Requirement

Achieving real-time decoding of LTE traffic requires a high-performance CPU with multiple physical cores. Especially when the base station has many active users during the peak hour. LTESniffer was able to achieve real-time decoding when running on an Intel i7-9700K PC to decode traffic on a base station with 150 active users.

The following hardware is recommended

• Intel i7 CPU with at least 8 physical cores
• At least 16Gb RAM
• 256 Gb SSD storage

SDR

LTESniffer requires different SDR for its uplink and downlink sniffing modes.

To sniff only downlink traffic from the base station, LTESniffer is compatible with most SDRs that are supported by the srsRAN library (for example, USRP or BladeRF). The SDR should be connected to the PC via a USB 3.0 port. Also, it should be equipped with GPSDO and two RX antennas to decode downlink messages in transmission modes 3 and 4.

On the other hand, to sniff uplink traffic from smartphones to base stations, LTESniffer needs to listen to two different frequencies (Uplink and Downlink) concurrently. To solve this problem, LTESniffer supports two options:

• Using a single USRP X310. USRP X310 has two Local Oscillators (LOs) for 2 RX channels, which can turn each RX channel to a distinct Uplink/Downlink frequency. To use this option, please refer to the main branch of LTESniffer.
• Using 2 USRP B-Series. LTESniffer utilizes 2 USRP B-series (B210/B200) for uplink and downlink separately. It achieves synchronization between 2 USRPs by using GPSDO for clock source and time reference. To use this option, please refer to the LTESniffer-multi-usrp branch of LTESniffer and its README.

Installation

Important note: To avoid unexpected errors, please follow the following steps on Ubuntu 18.04/20.04/22.04.

Dependencies

• Important dependency: UHD library version >= 4.0 must be installed in advance (recommend building from source). The following steps can be used on Ubuntu 18.04. Refer to UHD Manual for full installation guidance.

UHD dependencies:

sudo apt update
sudo apt-get install autoconf automake build-essential ccache cmake cpufrequtils doxygen ethtool \
g++ git inetutils-tools libboost-all-dev libncurses5 libncurses5-dev libusb-1.0-0 libusb-1.0-0-dev \
libusb-dev python3-dev python3-mako python3-numpy python3-requests python3-scipy python3-setuptools \
python3-ruamel.yaml

Clone and build UHD from source (make sure that the current branch is higher than 4.0)

git clone https://github.com/EttusResearch/uhd.git
cd <uhd-repo-path>/host
mkdir build
cd build
cmake ../
make -j 4
make test
sudo make install
sudo ldconfig

Download firmwares for USRPs:

sudo uhd_images_downloader

We use a 10Gb card to connect USRP X310 to PC, refer to UHD Manual [1], [2] to configure USRP X310 and 10Gb card interface. For USRP B210, it should be connected to PC via a USB 3.0 port.

Test the connection and firmware (for USRP X310 only):

sudo sysctl -w net.core.rmem_max=33554432
sudo sysctl -w net.core.wmem_max=33554432
sudo ifconfig <10Gb card interface> mtu 9000
sudo uhd_usrp_probe

• srsRAN dependencies:

sudo apt-get install build-essential git cmake libfftw3-dev libmbedtls-dev libboost-program-options-dev libconfig++-dev libsctp-dev

• LTESniffer dependencies:

sudo apt-get install libglib2.0-dev libudev-dev libcurl4-gnutls-dev libboost-all-dev qtdeclarative5-dev libqt5charts5-dev

Build LTESniffer from source:

git clone https://github.com/SysSec-KAIST/LTESniffer.git
cd LTESniffer
mkdir build
cd build
cmake ../
make -j 4 (use 4 threads)

Usage

LTESniffer has 3 main functions:

• Sniffing LTE downlink traffic from the base station
• Sniffing LTE uplink traffic from smartphones
• Security API

After building from source, LTESniffer is located in <build-dir>/src/LTESniffer

Note that before using LTESniffer on the commercial, one should have to check the local regulations on sniffing LTE traffic, as we explained in the Ethical Consideration.

To figure out the base station and Uplink-Downlink band the test smartphone is connected to, install Cellular-Z app on the test smartphone (the app only supports Android). It will show the cell ID and Uplink-Downlink band/frequency to which the test smartphone is connected. Make sure that LTESniffer also connects to the same cell and frequency.

General downlink sniffing

sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -C -m 0
example: sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -C -m 0
-A: number of antennas
-W: number of threads
-f: downlink frequency
-C: turn on cell search
-m: sniffer mode, 0 for downlink sniffing and 1 for uplink sniffing

Note: to run LTESniffer with USRP B210 in the downlink mode, add option -a "num_recv_frames=512" to the command line. This option extends the receiving buffer for USRP B210 to achieve better synchronization.

sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -C -m 0 -a "num_recv_frames=512"
example: sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -C -m 0 -a "num_recv_frames=512"

General uplink sniffing

Note: In the uplink sniffing mode, the test smartphones should be located nearby the sniffer, because the uplink signal power from UE is significantly weaker compared to the downlink signal from the base station.

sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -u <UL Freq> -C -m 1
example: sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -u 1745e6 -C -m 1
-u: uplink frequency

Security API

sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -u <UL Freq> -C -m 1 -z 3
example: sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -u 1745e6 -C -m 1 -z 3
-z: 3 for turnning on 3 functions of sniffer, which are identity mapping, IMSI collecting, and UECapability profiling.
    2 for UECapability profiling
    1 for IMSI collecting
    0 for identity mapping

Specify a base station

LTESniffer can sniff on a specific base station by using options -I <Phycial Cell ID (PCI)> -p <number of Physical Resource Block (PRB)>. In this case, LTESniffer does not do the cell search but connects directly to the specified cell.

sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -I <PCI> -p <PRB> -m 0
sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -u <UL Freq> -I <PCI> -p <PRB> -m 1
example: sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -u 1745e6 -I 379 -p 100 -m 1

The debug mode can be enabled by using option -d. In this case, the debug messages will be printed on the terminal.

Output of LTESniffer

LTESniffer provides pcap files in the output. The pcap file can be opened by WireShark for further analysis and packet trace. The name of downlink pcap file: sniffer_dl_mode.pcap, uplink pcap file: sniffer_ul_mode.pcap, and API pcap file: api_collector.pcap. The pcap files are located in the same directory LTESniffer has been executed. To enable the WireShark to analyze the decoded packets correctly, please refer to the WireShark configuration guide here. There are also some examples of pcap files in the link.
Note: The uplink pcap file contains both uplink and downlink messages. On the WireShark, use this filter to monitor only uplink messages: mac-lte.direction == 0; or this filter to monitor only downlink messages: mac-lte.direction == 1.

Application Note

Distance for uplink sniffing

The effective range for sniffing uplink is limited in LTESniffer due to the capability of the RF front-end of the hardware (i.e. SDR). The uplink signal power from UE is significantly weaker compared to the downlink signal because UE is a handheld device that optimizes battery usage, while the eNB uses sufficient power to cover a large area. To successfully capture the uplink traffic, LTESniffer can increase the strength of the signal power by i) being physically close to the UE, or ii) improving the signal reception capability with specialized hardware, such as a directional antenna, dedicated RF front-end, and signal amplifier.

The information displayed on the terminal

Downlink Sniffing Mode

Processed 1000/1000 subframes: Number of subframes was processed by LTESniffer last 1 second. There are 1000 LTE subframes per second by design.
RNTI: Radio Network Temporary Identifier of UEs.
Table: The maximum modulation scheme that is used by smartphones in downlink. LTESniffer supports up to 256QAM in the downlink. Refer to our paper for more details.
Active: Number of detected messages of RNTIs.
Success: Number of successfully decoded messages over number of detected messages (Active).
New TX, ReTX, HARQ, Normal: Statistic of new messages and retransmitted messages. This function is in development.
W_MIMO, W_pinfor, Other: Number of messages with wrong radio configuration, only for debugging.

Uplink Sniffing Mode

Max Mod: The maximum modulation scheme that is used by smartphones in uplink. It can be 16/64/256QAM depending on the support of smartphones and the configuration of the network. Refer to our paper for more details.
SNR: Signal-to-noise ratio (dB). Low SNR means the uplink signal quality from the smartphone is bad. One possible reason is the smartphone is far from the sniffer.
DL-UL_delay: The average of time delay between downlink signal from the base station and uplink signal from the smartphone.
Other Info: Information only for debugging.

API Mode

Detected Identity: The name of detected identity.
Value: The value of detected identity.
From Message: The name of the message that contains the detected identity.

Credits

We sincerely appreciate the FALCON and SRS team for making their great softwares available.

BibTex

Please refer to our paper for more details.

@inproceedings{hoang:ltesniffer,
  title = {{LTESniffer: An Open-source LTE Downlink/Uplink Eavesdropper}},
  author = {Hoang, Dinh Tuan and Park, CheolJun and Son, Mincheol and Oh, Taekkyung and Bae, Sangwook and Ahn, Junho and Oh, BeomSeok and Kim, Yongdae},
  booktitle = {16th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec '23)},
  year = {2023}
}

FAQ

Q: Is it mandatory to use GPSDO with the USRP in order to run LTESniffer?
A: GPSDO is useful for more stable synchronization. However, for downlink sniffing mode, LTESniffer still can synchronize with the LTE signal to decode the packets without GPSDO. For uplink sniffing mode, GPSDO is only required when using 2 USRP B-series, as it is the time and clock reference sources for synchrozation between uplink and downlink channels. Another uplink SDR option, using a single USRP X310, does not require GPSDO.

Q: For downlink traffic, can I use a cheaper SDR?
A: Technically, any SDRs supported by srsRAN library such as Blade RF can be used to run LTESniffer in the downlink sniffing mode. However, we only tested the downlink sniffing function of LTESniffer with USRP B210 and X310.

Q: Is it illegal to use LTESniffer to sniff the LTE traffic?
A: You should have to check the local regulations on sniffing (unencrypted) LTE traffic. Another way to test LTESniffer is setting up a personal LTE network by using srsRAN - an open-source LTE implementation in a Faraday cage.

Q: Can LTESniffer be used to view the content of messages between two users?
A: One can see only the "unencrypted" part of the messages. Note that the air traffic between the base station and users is mostly encrypted.

Q: Is there any device identity exposed in plaintext in the LTE network?
A: Yes, literature shows that there are multiple identities exposed, such as TMSI, GUTI, IMSI, and RNTI. Please refer to the academic literature for more details. e.g. Watching the Watchers: Practical Video Identification Attack in LTE Networks

NetworkAssessment - With Wireshark Or TCPdump, You Can Determine Whether There Is Harmful Activity On Your Network Traffic That You Have Recorded On The Network You Monitor

The Network Compromise Assessment Tool is designed to analyze pcap files to detect potential suspicious network traffic. This tool focuses on spotting abnormal activities in the network traffic and searching for suspicious keywords. 

• DNS Tunneling Detection: Identifies potential covert communication channels over DNS.
• SSH Tunneling Detection: Spots signs of SSH sessions which may be used to bypass network restrictions or cloak malicious activities.
• TCP Session Hijacking Identification: Monitors for suspicious TCP sessions which might indicate unauthorized takeovers.
• Various Attack Signatures: Recognizes indicators of SYN flood, UDP flood, Slowloris, SMB attacks, and more.
• Suspicious Keyword Search: Actively scans the network traffic for user-defined keywords that could be indicative of malicious intent or sensitive data leakage.
• Protocol-Specific Scanning: Allows users to specify which protocols to monitor, ensuring focused and efficient analysis.
• Output Logging: Provides an option to save detailed analysis results to a file for further investigation or record-keeping.
• IPv6 Fragmentation Attack Detection: Spots potential attempts to exploit the fragmentation mechanism in IPv6 for nefarious purposes.
• User-Friendly Display: Color-coded outputs and progress indicators enhance readability and user experience.

The tool is not just limited to the aforementioned features. With contributions from the community, its detection capabilities can continuously evolve and adapt to the latest threat landscape.

• Python 3.x
• scapy
• argparse
• pyshark
• colorama

1. Clone the repository:

   git clone https://github.com/HalilDeniz/NetworkAssessment.git

2. Navigate to the project directory:

   cd NetworkAssessment

3. Install the required dependencies:

   pip install -r requirements.txt

python3 networkassessment.py [-h] -f FILE [-p {TCP,UDP,DNS,HTTP,SMTP,SMB} [{TCP,UDP,DNS,HTTP,SMTP,SMB} ...]]
                            [-o OUTPUT] [-n NUMBER_PACKET]

• -f or --file: Path to the .pcap or .pcapng file you intend to analyze. This is a mandatory field, and the assessment will be based on the data within this file.
• -p or --protocols: Protocols you specifically want to scan. Multiple protocols can be mentioned. Available choices are: "TCP", "UDP", "DNS", "HTTP", "SMTP", "SMB".
• -o or --output: Path to save the scan results. This is optional. If provided, the findings will be saved in the specified file.
• -n or --number-packet: Number of packets you wish to scan from the provided file. This is optional. If not specified, the tool will scan all packets in the file.

In the above example, the tool will analyze the first 1000 packets of the sample.pcap file, focusing on the TCP and UDP protocols, and will then save the results to output.txt.

Contributions are welcome! If you find any issues or have suggestions for improvements, feel free to open an issue or submit a pull request.

If you have any questions, comments, or suggestions about Dosinator, please feel free to contact me:

• LinkedIn: Halil Ibrahim Deniz
• TryHackMe: Halilovic
• Instagram: deniz.halil333
• YouTube: Halil Deniz
• Email: halildeniz313@gmail.com

NetworkAssesment is a fork of the original tool called Network_Assessment, which was created by alperenugurlu. I would like to express my gratitude to Alperen Uğurlu for the inspiration and foundation provided by the original tool. Without his work, this updated version would not have been possible. If you would like to learn more about the original tool, you can visit the Network_Assessment repository.

This project is licensed under the MIT License. See the LICENSE file for more details.

Thank you for considering supporting me! Your support enables me to dedicate more time and effort to creating useful tools like DNSWatch and developing new projects. By contributing, you're not only helping me improve existing tools but also inspiring new ideas and innovations. Your support plays a vital role in the growth of this project and future endeavors. Together, let's continue building and learning. Thank you!"

Bryobio - NETWORK Pcap File Analysis

NETWORK Pcap File Analysis, It was developed to speed up the processes of SOC Analysts during analysis

Tested

OK Debian
OK Ubuntu

Requirements

$ pip install pyshark
$ pip install dpkt

$ Wireshark
$ Tshark
$ Mergecap
$ Ngrep

𝗜𝗡𝗦𝗧𝗔𝗟𝗟𝗔𝗧𝗜𝗢𝗡 𝗜𝗡𝗦𝗧𝗥𝗨𝗖𝗧𝗜𝗢𝗡𝗦

$ https://github.com/emrekybs/Bryobio.git
$ cd Bryobio
$ chmod +x bryobio.py

$ python3 bryobio.py

Nac_Bypass_Agent - This Function Combines All The Above Functions And Takes Necessary Information From The User To Change The IP And MAC Address, Start The Responder And Tcpdump Tools, And Run The Nbtscan Tool

Nac Bypass Agent

This piece of code is a script written in Python and designed to run on Kali Linux. Here is a summary explaining what each function does:

run_command(command):

This function runs the command it takes as input and returns its output.

kill_network_services():

This function stops the dhclient and NetworkManager services.

get_network_info():

This function listens for network traffic using tcpdump and returns the first captured IP and MAC address. If these addresses are not captured, None returns None.

spoof_ip_address(interface, ip_address, netmask):

This function replaces the IP address of the specified network interface with the specified IP address and netmask.

spoof_mac_address(interface, mac_address):

This function replaces the MAC address of the specified network interface with the specified MAC address.

start_responder(interface):

This function starts the responder tool on the specified network interface.

start_tcpdump(interface):

This function starts the tcpdump tool on the specified network interface.

nbtscan(ip_range):

This function runs the nbtscan tool in the specified IP range.

main():

This function combines all the above functions and takes necessary information from the user to change the IP and MAC address, start the responder and tcpdump tools, and run the nbtscan tool.

All of the above code must be contained in a Python script and the script must be run with root privileges. Because this piece of code contains commands that change the network configuration and tools that listen for network traffic. These operations usually require root privileges. Also, the use of this script may be subject to the law and unauthorized use may lead to legal problems. Therefore, it is important to check local laws and policies before using the script.

In apt and Ransomware group scenarios, when they infiltrate the enterprise from the outside, it tries to bypass nac security solutions in enterprise structures. If it can achieve this, it starts to discover users in the whole network. It also listens to the network with wireshark or tcpdump. If voip is used in your structure, it can decode all calls over SIP. In the scenario I have described below, it decodes your voip calls over SIP after success.

This is a tool that aims to automatically bypass the nac bypass method at the basic level in the tool I have made. With this tool, it helps you to interpret your nac security product configuration in your organization with or without attack protection at a basic level. Example usage and explanation are as follows.

Step 1

The first step is to run this tool when you connect to the inside network.

If the nac bypass is successful, listen to the network with wireshark. And here, filter the Voip calls from the #SIPFlows tab from the #Telephony tab with the data you collected over wireshark, and if the call is available instantly, you can listen to the VOIP calls according to a certain order.

Step 2

Step 3

The purpose of this tool and this scenario is to increase security awareness for your institutions. In addition, the perspective of an APT group has been tried to be reflected.

Everyone is looking at what you are looking at; But can everyone see what he can see? You are the only difference between them…

By Mevlânâ Celâleddîn-i Rûmî

Network_Assessment - With Wireshark Or TCPdump, You Can Determine Whether There Is Harmful Activity On Your Network Traffic That You Have Recorded On The Network You Monitor

With Wireshark or TCPdump, you can determine whether there is harmful activity on your network traffic that you have recorded on the network you monitor.

This Python script analyzes network traffic in a given .pcap file and attempts to detect the following suspicious network activities and attacks:

1. DNS Tunneling
2. SSH Tunneling
3. TCP Session Hijacking
4. SMB Attack
5. SMTP or DNS Attack
6. IPv6 Fragmentation Attack
7. TCP RST Attack
8. SYN Flood Attack
9. UDP Flood Attack
10. Slowloris Attack

The script also tries to detect packages containing suspicious keywords (eg "password", "login", "admin", etc.). Detected suspicious activities and attacks are displayed to the user in the console.

The main functions are:

• get_user_input(): Gets the path of the .pcap file from the user.
• get_all_ip_addresses(capture): Returns a set containing all source and destination IP addresses.
• detect_* functions: Used to detect specific attacks and suspicious activities.
• main(): Performs the main operations of the script. First, it gets the path of the .pcap file from the user, and then analyzes the file to try to detect the specified attacks and suspicious activity.

How to Install Script?

git clone https://github.com/alperenugurlu/Network_Assessment.git

pip3 install -r requirements.txt

How to Run the Script?

python3 Network_Compromise_Assessment.py

Please enter the path to the .pcap or .pcapng file: /root/Desktop/TCP_RST_Attack.pcap (Example)

Script Creator

Alperen Ugurlu

Social Media:

https://www.linkedin.com/in/alperen-ugurlu-7b57b7178/