> For the complete documentation index, see [llms.txt](https://docs.didge.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didge.io/home/foodcore-sensors/technical/hardware-specs/multitech-gateways/internal-pentest.md).

# Internal Pentest

## Penetration Testing Report – MultiTech Conduit AP Gateway (MTCAP)

**Device Tested:** MultiTech Conduit AP LoRaWAN Gateway – SIM-Enabled Model (MTCDT Series)

**Test Date:** 22/10/2024

**Tested By:** MFC Safe

***

### Executive Summary

This report summarizes the results of penetration testing performed on the MultiTech MTCAP gateway. The evaluation focused on physical security, network access control, firmware protection, authentication, and LoRaWAN data handling. The device was found to exhibit a strong security posture with minor medium-risk concerns around physical port access and password policy enforcement.

| Test Category           | Result Summary                          | Risk Level |
| ----------------------- | --------------------------------------- | ---------- |
| Physical Port Access    | USB/serial interfaces exposed           | Low        |
| Firmware Protection     | Verified firmware signing/encryption    | Low        |
| Web Interface Security  | Login required, CSRF patches applied    | Low        |
| Network Exposure        | Port filtering and firewall effective   | Low        |
| Authentication & Access | Credentials enforced, weak policy       | Low        |
| OTA Updates             | Encrypted OTA supported                 | Low        |
| LoRaWAN Packet Handling | AES-128 encryption, packet integrity OK | Low        |
| CVE Assessment          | No exploitable known CVEs found         | Low        |

***

### Test Details & Findings

#### 1. Physical Port Security

* **Finding:** Serial and USB debug ports exposed.
* **Impact:** Allows local tampering or data interception.
* **Recommendation:** Restricted physical access, Disable or seal ports in production.
* **Risk:** Low

#### 2. Firmware Security

* **Finding:** Firmware requires signature validation to install.
* **Result:** No bypass vulnerabilities discovered.
* **Risk:** Low

#### 3. Web Admin Panel

* **Finding:** Login page protected with HTTPS; CSRF mitigated.
* **Result:** Login brute-force protection limited.
* **Recommendation:** Enforce stronger password policies.
* **Risk:** Low–Medium

#### 4. Network Exposure & Firewall

* **Finding:** Default services limited to SSH and HTTPS.
* **Result:** Open port scan revealed no exposed insecure services.
* **Risk:** Low

#### 5. Authentication and Credential Storage

* **Finding:** Restricted physical access, password hashing in place, but minimum complexity requirements not enforced by default.
* **Risk:** Low

#### 6. OTA Update Mechanism

* **Finding:** OTA updates over HTTPS with signature validation.
* **Risk:** Low

#### 7. LoRaWAN Data Handling

* **Finding:** End-to-end AES-128 encryption supported and validated.
* **Risk:** Low

#### 8. Vulnerability Assessment

* **Finding:** Checked against recent CVEs; no known issues affecting this model.
* **Risk:** Low

***

### Recommendations

* **Harden physical device access** in deployment locations.
* **Enforce password rotation and complexity** standards.
* **Update firmware regularly** in line with MultiTech advisories.

***

### Conclusion

The MultiTech Conduit AP Gateway demonstrates solid performance in all assessed security domains. The primary concerns are physical and password-related, which are manageable with appropriate deployment controls. This device is fit for use in regulated and secure environments.

***

*This document is prepared for internal security review and/or client assurance reporting.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.didge.io/home/foodcore-sensors/technical/hardware-specs/multitech-gateways/internal-pentest.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.