Signal K Server is a server application that runs on a central hub in a boat. Prior to version 2.25.0, the HTTP login endpoints (POST /login and POST /signalk/v1/auth/login) are protected by express-rate-limit (default: 100 attempts per 10-minute window, configurable via HTTP_RATE_LIMITS). The WebSocket login path — sending {login: {username, password}} messages over an established WebSocket connection — calls app.securityStrategy.login() directly without any rate limiting. An attacker can bypass HTTP rate limiting entirely by opening a WebSocket connection and attempting unlimited password guesses at the speed bcrypt allows (~20 attempts/sec with 10 salt rounds). This issue has been patched in version 2.25.0.
Signal K Server versions prior to 2.25.0 contain a critical authentication bypass vulnerability allowing attackers to circumvent HTTP rate limiting on login endpoints by exploiting unprotected WebSocket login functionality. Attackers can perform unlimited password guessing attacks at ~20 attempts per second, significantly increasing brute-force attack success probability. This vulnerability affects maritime vessel management systems and IoT infrastructure commonly deployed in Saudi Arabian ports and offshore operations.
IMMEDIATE ACTIONS:
1. Identify all Signal K Server instances in your environment using network scanning and asset inventory tools
2. Isolate affected systems from public internet access; restrict WebSocket connections to trusted networks only
3. Implement network-level rate limiting on WebSocket connections (IDS/IPS rules)
4. Monitor WebSocket login attempts for suspicious patterns (multiple failed attempts from single source)
PATCHING:
1. Upgrade Signal K Server to version 2.25.0 or later immediately
2. Test patches in non-production environments first
3. Coordinate patching with vessel operations to minimize downtime
COMPENSATING CONTROLS (if immediate patching not possible):
1. Implement WAF/reverse proxy rules to rate-limit WebSocket /login messages
2. Deploy network segmentation: restrict WebSocket access to authorized administrative networks only
3. Enable strong authentication: enforce multi-factor authentication (MFA) for all user accounts
4. Implement account lockout policies: lock accounts after 5 failed login attempts for 30 minutes
5. Deploy SIEM rules to detect and alert on rapid WebSocket login attempts (>10 attempts/minute from single IP)
DETECTION:
1. Monitor WebSocket connection logs for repeated login failures
2. Alert on connection patterns: multiple WebSocket connections from same source IP
3. Track bcrypt operation timing anomalies (sustained high CPU usage from login processes)
4. Log all successful logins with source IP, timestamp, and user account for forensic analysis
الإجراءات الفورية:
1. تحديد جميع مثيلات خادم Signal K في بيئتك باستخدام أدوات المسح الشبكي وجرد الأصول
2. عزل الأنظمة المتأثرة عن الإنترنت العام؛ تقييد اتصالات WebSocket للشبكات الموثوقة فقط
3. تنفيذ تحديد معدل على مستوى الشبكة لاتصالات WebSocket (قواعد IDS/IPS)
4. مراقبة محاولات تسجيل الدخول عبر WebSocket للأنماط المريبة (محاولات فاشلة متعددة من مصدر واحد)
التصحيح:
1. ترقية خادم Signal K إلى الإصدار 2.25.0 أو أحدث على الفور
2. اختبار التصحيحات في بيئات غير الإنتاج أولاً
3. تنسيق التصحيح مع عمليات السفن لتقليل وقت التوقف
الضوابط البديلة (إذا لم يكن التصحيح الفوري ممكناً):
1. تنفيذ قواعد WAF/reverse proxy لتحديد معدل رسائل WebSocket /login
2. نشر تقسيم الشبكة: تقييد وصول WebSocket للشبكات الإدارية المصرح بها فقط
3. تفعيل المصادقة القوية: فرض المصادقة متعددة العوامل (MFA) لجميع حسابات المستخدمين
4. تنفيذ سياسات قفل الحساب: قفل الحسابات بعد 5 محاولات تسجيل دخول فاشلة لمدة 30 دقيقة
5. نشر قواعد SIEM للكشف والتنبيه عن محاولات تسجيل الدخول السريعة عبر WebSocket (>10 محاولات/دقيقة من عنوان IP واحد)
الكشف:
1. مراقبة سجلات اتصال WebSocket لفشل تسجيل الدخول المتكرر
2. التنبيه على أنماط الاتصال: اتصالات WebSocket متعددة من عنوان IP نفسه
3. تتبع شذوذ توقيت عملية bcrypt (استخدام CPU مرتفع مستدام من عمليات تسجيل الدخول)
4. تسجيل جميع عمليات تسجيل الدخول الناجحة مع عنوان IP والطابع الزمني واسم حساب المستخدم للتحليل الجنائي