How to check for malware or security threats?

Check for malware or security threads

Now I have enough information to provide a comprehensive security report. Let me compile it:

##Security Analysis Report: webosbrew/dev-manager-desktop

Based on my thorough analysis of the codebase, here's a comprehensive security assessment:

##⚠️ CRITICAL SECURITY ISSUES

###1. SSH Host Key Verification Disabled (CRITICAL - MITM Attack Risk)

Location: src/app/info/renew-script/renew-script.sh.ts:33

SESSION_TOKEN=$(ssh -i "${PRIV_KEY_FILE}" \
  -o ConnectTimeout=3 -o StrictHostKeyChecking=no \
  ...

Issue: The script disables SSH host key verification (StrictHostKeyChecking=no), making it vulnerable to Man-in-the-Middle (MITM) attacks. An attacker could intercept the connection and steal credentials or inject malicious data.

Risk Level: Critical - Allows attackers to intercept SSH sessions Impact: Could lead to credential theft, session hijacking, or device compromise

##🔴 HIGH SEVERITY ISSUES

###2. Credentials Stored in Plain Text (HIGH)

Location: src-tauri/src/device_manager/io.rs

// Devices configuration stored in plain JSON without encryption
pub(crate) async fn write(devices: Vec<Device>, conf_dir: &Path) -> Result<(), Error> {
    // ... creates devices.json with all credentials in plain text
    serde_json::to_writer_pretty(writer, &devices)?;
}

Issue:

• SSH private keys are stored in plain text in novacom-devices.json
• Passwords and passphrases are stored unencrypted
• Device tokens are stored in plain text
• File permissions are set to readable (0o644 on Unix)

Risk Level: High - Compromised local file system = compromised device access Impact: If an attacker gains access to the configuration directory, they can access all managed devices

Recommendation: Use OS-level credential storage:

• Windows: Use DPAPI (Data Protection API)
• macOS: Use Keychain
• Linux: Use Secret Service DBus interface

###3. No Encryption for Private Keys (HIGH)

Location: src-tauri/src/device_manager/privkey.rs

Private keys embedded in device configuration are stored as base64-encoded plain text with no encryption layer.

Risk Level: High Impact: Private keys are accessible to any process running with user privileges

##🟡 MEDIUM SEVERITY ISSUES

###4. Command Shell Injection Risk (MEDIUM)

Location: src/app/core/services/remote-luna.service.ts:32

While the code uses escapeSingleQuoteString() for escaping, there's potential for shell injection if:

• The function isn't applied consistently everywhere
• New code paths are added without proper escaping

export function escapeSingleQuoteString(value: string) {
    return value.split('\'').map(s => `'${s}'`).join('\\\'');
}

Issue: Shell command construction through string concatenation Recommendation: Consider using array-based command execution instead of shell strings where possible

###5. No SSH Known Hosts File (MEDIUM)

Location: src-tauri/src/conn_pool/connection.rs:115-124

#[cfg(windows)]
{
    session.set_option(SshOption::KnownHosts(Some("C:\\nul".to_string())))?;
    session.set_option(SshOption::GlobalKnownHosts(Some("C:\\nul".to_string())))?;
}

#[cfg(not(windows))]
{
    session.set_option(SshOption::KnownHosts(Some(format!("/dev/null"))))?;
    session.set_option(SshOption::GlobalKnownHosts(Some(format!("/dev/null"))))?;
}

Issue: SSH connections bypass known_hosts verification entirely by pointing to /dev/null Risk Level: Medium - Allows any SSH server to connect without verification Recommendation: Implement proper host key verification or at least warn users

##🟢 POSITIVE SECURITY PRACTICES

✅ Strong SSH Configuration

• Proper cipher suites configured (no weak algorithms like DES)
• Uses modern key exchange algorithms (Curve25519, ECDH)
• Uses strong MAC algorithms (HMAC-SHA2-256/512)
• Timeout set (10 seconds)

✅ No Dangerous Functions

• No eval(), exec() with shell strings
• No innerHTML assignments without sanitization
• No dangerouslySetInnerHTML patterns

✅ Proper Input Sanitization

• HTML content is sanitized using Angular's DomSanitizer
• Markdown is processed with marked and sanitized
• URL pipes properly use bypassSecurityTrustUrl only for URLs

✅ No Obvious Hardcoded Credentials

• No API keys, tokens, or passwords hardcoded in source

✅ HTTPS for External Communications

• Uses HTTPS for remote requests (update checks, Luna API)

✅ No console.log() of Sensitive Data

• Private keys/passwords not logged to console

##📋 SUMMARY TABLE

##🛠️ RECOMMENDATIONS

###Immediate Actions:

1. Enable SSH host key verification - Remove StrictHostKeyChecking=no
2. Implement secure credential storage - Use OS keychains/credential managers
3. Encrypt private keys at rest - Add encryption layer for stored credentials

###Short-term:

4. Implement host key pinning or known_hosts management
5. Add security warnings for plaintext credential storage
6. Consider adding device credential export encryption

###Long-term:

7. Regular security audits
8. Implement certificate pinning for HTTPS connections
9. Add optional end-to-end encryption for sensitive operations

##Conclusion

The application has solid general security practices but suffers from critical vulnerabilities in SSH configuration and credential storage. The most urgent issue is the disabled SSH host key verification, which leaves users vulnerable to MITM attacks. Combined with plaintext credential storage, this creates a significant security risk.

But the credentials and private keys are stored on device or on some server?

Let me provide you with the clarified answer about storage locations:

##Where Credentials and Private Keys Are Stored

All credentials and keys are stored on the local device (user's computer), NOT on any server. This is a desktop application that manages device connections locally.

###1. Configuration Directory: .webos/ose/ (or .webos\ose on Windows)

Path:

• Windows: C:\Users\{username}\AppData\Roaming\.webos\ose\
• Linux/macOS: ~/.webos/ose/

Contains: novacom-devices.json file with:

• Device connection details (name, host, port, username)
• SSH passwords (if user chose password auth) - PLAIN TEXT
• Private key content (if embedded in config) - BASE64 ENCODED, NOT ENCRYPTED
• Private key passphrases - PLAIN TEXT
• Device session tokens/Dev Mode tokens - PLAIN TEXT

Example structure:

{
  "name": "My TV",
  "host": "192.168.1.100",
  "port": 22,
  "username": "root",
  "password": "mypassword",  // ⚠️ PLAIN TEXT
  "private_key": {
    "data": "LS0tLS1CRUdJTi..."  // ⚠️ BASE64 ONLY (not encrypted)
  },
  "passphrase": "key_passphrase"  // ⚠️ PLAIN TEXT
}

###2. SSH Directory: .ssh/

Path:

• Windows: C:\Users\{username}\.ssh\
• Linux/macOS: ~/.ssh/

Permissions:

• Unix: 0o700 (rwx------) - Only user can read/write/execute

Contains:

• Referenced SSH private key files
• App-generated SSH key: id_devman for internal use

###3. Temporary Caches: /tmp/ (system-specific)

When using the "Renew Dev Mode" feature:

• Temporary SSH keys created in /tmp/renew-script.{PID}/
• Device token cache in /tmp/webos_devmode_token_{DEVICE_NAME}.txt

##Key Findings Summary

##Security Implications

###High Risk Scenarios:

1. If your computer is compromised → Attacker gains access to:

   • All stored passwords
   • All SSH private keys
   • All device tokens
   • Full access to all managed webOS devices

2. If .webos/ose/ directory is accessible → Anyone with file system access can:

   • Read all credentials in plain text
   • Use private keys to connect to TVs
   • Access stored session tokens

3. No encryption layer → Unlike ~/.ssh which relies on file permissions, the JSON config doesn't use OS-level credential storage (keychains, credential managers)

##Good News:

• ✅ Data is stored locally, NOT sent to remote servers
• ✅ Only accessible if attacker gains local file system access
• ✅ .ssh folder has proper Unix permissions (0o700)

##Bad News:

• ❌ Credentials stored in plain text JSON
• ❌ No encryption at rest
• ❌ No use of OS-level credential storage (Windows DPAPI, macOS Keychain, Linux Secret Service)
• ❌ Config file has overly permissive permissions (0o644 on Unix)

Recommendation: This application is suitable for development environments but should NOT be used in high-security scenarios where the computer may be compromised. Consider using the native ares-cli which stores credentials more securely.