Caster - Running Caster

Running and Starting Caster For The First Time

After you are done installing SkyLine, you pretty much have everything you need to run Caster. Before you actually scan for something, here are some rules about Caster you should understand.

• Must Be Root: Caster initiates a plugin that utilizes some deep IO control, especially with interfaces. Not to mention, the module also needs direct access to network interfaces for packet capturing and distribution. So, you must run the framework by calling the SkyLine interpreter as a root user.

• Must Supply An Interface: Given that Caster uses the framework to send specific payloads, especially to API endpoints and distributes ARP packets, the framework needs a useable interface. But, mostly on the security end, if the interface is not considered "Stable" based on the supplied range, mask, and various other factors, then the framework will skip and use a random interface from the list of interfaces provided. You can provide an interface to caster with `--interface="interface.wlan0"`

These two factors will help you work with Caster a bit more. So, lets get started. The next few sections will explain different modules and sections of Caster.

Running Caster | Help

The help module within caster has two settings: command and console based menus. Each menu is all drawn out for tables, so, lets go ahead and go through them.

sudo SkyLine caster.sl --help

The image below is of the standard output from the command run above.

Image of the caster help menu

Now, Caster also splits its flag usage into two different categories which are the following listed below.

• Required / Console-Based Flags: These flags are not used for general scripting and are primarily used for the interactive mode. The difference between the command line mode and the interactive mode is that the interactive mode actually uses the scripting module for ARP relay. These flags are also going to be used for general configuration. The flags for this section are defined as the following.

Sub point - Required and console based flags

--> --interface : This will specify an interface for the packet relay module used within Caster, if none is supplied, the module will attempt to find and pick an interface that is easier to use and capture based on the environment.

--> --strict : This flag is mainly applied to the console mode since the console mode relies on hosts that have been captured already and are loaded during runtime.

--> --debug: Debug output is automatically enabled when you are not in the interactive or console mode, so, if you want debug output when using the console, make sure to specify debug before any other flag including required ones.

--> --arpdelim : When using the console, the ARP module is setup immediately and is set to send out more than 2 packets per host on the network. The arpdelim option stands for delimiter which will be telling Caster how long you want to wait until the next batch of ARP packets is produced.

--> --arp: This flag has to options - "on" and "off" which look like this --arp=on and --arp=off which will tell Caster to either enable or disable the ARP module. Its important that if you are using the console-based mode this module is specified to be ON.

--> --import: Will import the latest scanned file instead of starting a new one. Basically, when you enter the console, any saved or captured host in the TargetInfo.json file will be loaded into the environment.

Sub Point - Command Line Based Flags

• Command Line Based Flags: Casters command line mode is super helpful especially when wanting to analyze different parts of unique file formats and more. It also helps for quick enumeration and in the future- quick reporting. However, it is important to know that the flags shown below are the only ones that actively work for people who do not want to use the console. Also, understand that it is an absolute must to be using the --cli flag when wanting to use command line options. Flags are shown below.

--> --target: This flag is there to help you specify a target IP address. Mostly, if you do not specify specific patterns of flags, then Casters command line mode will not use the target database. Mainly because you are going to be targeting a device that may be set remotely. Please make sure this flag comes first, this is a positional-based argument.

--> --stringbplist: This will take a given bplist file and not only verify the file but also grab out some specific strings. Granted, you should just use strings it for this and could probably pipe it from curl but this was really just a core demonstration of SkyLine's ability to easily string out data in one function call LMAO. Not to mention, using the strings tool might give you more mobility.

--> --current: This option is not that hard and actually works for both console and command line users. This will basically output the target configuration that is used for the console targeting.

--> --databases: In the future, Caster will allow enumeration from the command line version or module of the framework, sorry, non-interactive to be specific. This will output all of the brands that Caster can verify when --strict is turned off.

Running Caster | The Dangers Of --strict=off

As talked about, there is a unique option for the console called --strict which can make Caster much more strict on enumeration and also add more rules to the process of targeting a host or it can give you complete control and complete trust in the user to supply not only a valid IP address but also a very valid operating system and database for Caster.

Here is a breakdown of it: on the backend, especially in the console, when you set a device with its IP address, Caster will open the Capture.json file and search for that host. If the host exists, it will open up TargetInfo.json and write the following values to it.

--> Database: The database field is the type of database of existing payloads and APIs that Caster will call from SkyLines backend to ensure it is manipulating the same exact data.

--> IP: Just the IP address you specified

--> Brand: This is the brand of the device for example Google.

When you set a target or device, Caster will fill the file up like the following.

{
    "Device": [
        {
            "IP": "10.0.0.68",
            "Brand": "Amazon Technologies Inc.",
            "Database": "" 
        }
    ]
}

This file is important in two ways, one being verification and the other for control and better speeds and performance.

So, what's the issue when turning strict off?

Well, when Caster operates normally, it uses the file above and will compare your IP address to the brand name. If the brand name set in the target is correct also will then check the database and see if it matches up when you use a console command for enumeration. For example, if you use enumerate apple-airplayinfo then Caster will take the first part of the command which in this case is apple after enumerate is popped from the command parser and then checks the current set database for the target. The code brick shown below demonstrates this.

  if (EnumerateCommand.Contains("apple") == true) {
                    if (DeviceDB == "apple") {
                        Requesting::EnumerateDevice(EnumerateCommand, Target)
                    } else {
                        println("Error: You can not target an apple device on this address. The device must be an Apple device")
                    }
                } else if (EnumerateCommand.Contains("roku") == true) {
                    if (DeviceDB == "roku") {
                        Requesting::EnumerateDevice(EnumerateCommand, Target)
                    } else {
                        println("Error: You can not target a Roku device on this address. The device must be an Roku device")
                    }
                } else if (EnumerateCommand.Contains("google") == true) {
                    if (DeviceDB == "google") {
                        Requesting::EnumerateDevice(EnumerateCommand, Target)
                    } else {

                    }
                } else if (EnumerateCommand.Contains("amazon") == true) {
                    if (DeviceDB == "amazon") {
                        Requesting::EnumerateDevice(EnumerateCommand, Target)
                    } else {
                        println("Error: You can not target a Amazon device on this address. The device must be an Amazon device")
                    }
                } else {
                    println("Unsupported brand")
                }
            }

The primary issue here is that when an HTTP request, payload, or something fails due to a connection with the host on the backend, the SkyLine evaluator will fail and stop all further execution and evaluation will basically crash Caster.

> Example

Let's say we find a device on Shodan, want to plug it in, and see what we can do with it. We know that Caster wants to make sure the host is in the file before setting it, so we can specify the target beforehand and configure the target for the console session. So, let's run the following command.

sudo SkyLine Caster.sl --strict=off --debug --interface=enp10s0 --target=x.x.x.x

When we run the command we get prompted to the console with no issues and we are brought to the following screen after running the console command view settings

When we run the command enumerate apple-serverinfo which is used to grab AirPlay server information from the device, we get the following output.

[Caster@Local](Command)>enumerate apple-serverinfo
Error calling function `&{{TOKEN_IDENT http.Get} http.Get}` : HTTP request failed 
Error calling function `&{{[ [} %!s(*SkyLine_Backend_Abstract_Synatax_Tree.SL_Identifier=&{{TOKEN_IDENT MapOCommands} MapOCommands}) %!s(*SkyLine_Backend_Abstract_Synatax_Tree.SL_Identifier=&{{TOKEN_IDENT command} command})}` : HTTP request failed 
[Caster@Local](Command)>

While the console did return and just return control, the SkyLine interpreter in some states such as making an active empty-POST request and even going as far as making specific PUT requests, will crash if there is an error within the HTTP module especially if it is around TLS based requests.

Note: It is generall suggested that you make SURE strict is turned on and not off when you run the framework. --strict is not a specific flag that is required but is still suggested.