6.42+ persistent exploit

[caiot5]

Hello,

I've playing around with your 6.42+ mikrotik (flashdrive) exploit and I was wondering if may it be possible to create a persistent method. I tried to add to the line that creates the tmp file which is used to execute the mount -o bind command another echo which would output to a new /rw/pckg/defconf when it boots, sort of defconf loop ;)

Something like: echo "; mkdir /pckg/option; mount -o bind /boot/ /pckg/option; ln -s / /rw/pckg/.root; echo \"\; mkdir /pckg/option\; mount -o bind /boot/ /pckg/option\; ln -s / /rw/pckg/.root\; \" \> /rw/pckg/DEFCONF ;" > /tmp/$JBID

EDIT: The text above was supposed to have several backslash characters trying to avoid the first echo to execute the commands of the second echo which was supposed to be executed only at boot but looks like github doesn't allow this. Maybe if you try to edit my post, then you can see the backslash characters.

But it hasn't worked. Anyway, I'm not a programmer, just a little bit curious.

Do you think something like that can be done? Maybe something else?

P.S. Thank you for your work! Great tools!

[yourchanges]

you can easily create a daemon process, do a interval check and re-create file /flash/rw/DEFCONF with content:

; mkdir /pckg/option; mount -o bind /boot/ /pckg/option; ln -s / /rw/pckg/.root; cd /flash/bin ; /flash/bin/rosadmin ; cd -  ;

PS: my daemon process path is /flash/bin/rosadmin.

so when reboot, the daemon process prepare the DEFCONF for next reboot.

and it works successfully on my 10 devices.

[0ki]

Glad you managed to get this working.

[up777]

thank you very much

[nathanap1]

@yourchanges wrote:

and it works successfully on my 10 devices.

I had a similar idea that I tried a couple weeks before you posted this, and it does work, but it has a very bad side-effect.

If a file exists at /flash/rw/DEFCONF, it doesn't matter what the contents of that file are (it could be completely empty), but as long as it is there, the router will eventually stop accepting logins. Telnet, SSH, Winbox, etc. ...it will just freeze at authentication and time out after a minute or so.

In fact, if you edit second_stage.sh to remove the part where it sends the router a reboot command, the same problem will happen just by virtue of the fact that the script created a DEFCONF file on the router.

I have tried this on 6.41 through 6.45 and it happens every time with every version. So I don't understand how you could have "success" with this method.

Interestingly, if you log in, create the file, and then stay logged in (keep at least one session active), you can continue to establish other sessions and log in and out of the router without any problem. But once the last active session is shut down, if /flash/rw/DEFCONF is still in place, the router will stop accepting logins (though sometimes it can take a minute or so before the problem occurs...so if you create /flash/rw/DEFCONF, log out, and then IMMEDIATELY log back in again, it will probably still work).

You said that you created a daemon process that does "a interval check". Unfortunately you didn't post the source to your daemon so it's unclear exactly what it is doing.

DEFCONF actually doesn't get deleted by the system except on bootup (after it has been executed), so I don't think checking for its existence at intervals is necessary. My own strategy was to simply copy the DEFCONF file to another location, fork a shell process that sleeps for 20 seconds after bootup, and then copies the file back into place, like so:

; mkdir /pckg/option; mount -o bind /boot/ /pckg/option; ln -s / /rw/pckg/.root; cp /rw/DEFCONF /rw/pckg/re-jailbreak; ((usleep 20000000; cp /rw/pckg/re-jailbreak /rw/DEFCONF;)>/dev/null 2>&1 &);

Although you said that your daemon does an "interval check", you also mentioned that "when reboot, the daemon process prepare the DEFCONF for next reboot". This gives me an idea: perhaps if you write a daemon that waits for SIGTERM, and then only creates DEFCONF when it receives that signal, that would work.

The downside to this, though, is that if the router is not shutdown or restarted cleanly (power failure, etc.) then you will have to re-jailbreak again with an external process (e.g. second_stage.sh).

Could you please clarify exactly what your daemon is doing, and if it really is checking for DEFCONF at intervals and re-creating it, how could that be working for you? Have you really never run into the problem where RouterOS stops letting you log in if DEFCONF exists?

[yourchanges]

in my daemon process, I do the two things in order :

1. automatically do a ssh login, to make sure around the "login die check"; such as(in golang):

   session, err := connect("devel", "xxxx", "127.0.0.1", 22)

2. when 1 success, create a /flash/rw/DEFCONF. you can get it works correctly. And I do it in my daemon process with golang like this:

   copy("/flash/bin/DEFCONF", "/flash/rw/DEFCONF")

nathanap1 notifications@github.com 于2019年7月6日周六 上午9:57写道：

and it works successfully on my 10 devices.

I had a similar idea that I tried a couple weeks before you posted this, and it does work, but it has a very bad side-effect.

If a file exists at /flash/rw/DEFCONF, it doesn't matter what the contents of that file are (it could be completely empty), but as long as it is there, the router will eventually stop accepting logins. Telnet, SSH, Winbox, etc. ...it will just freeze at authentication and time out after a minute or so.

In fact, if you edit second_stage.sh to remove the part where it sends the router a reboot command, the same problem will happen just by virtue of the fact that the script created a DEFCONF file on the router.

I have tried this on 6.41 through 6.45 and it happens every time with every version. So I don't understand how you could have "success" with this method.

Interestingly, if you log in, create the file, and then stay logged in (keep at least one session active), you can continue to establish other sessions and log in and out of the router without any problem. But once the last active session is shut down, if /flash/rw/DEFCONF is still in place, the router will stop accepting logins (though sometimes it can take a minute or so before the problem occurs...so if you create /flash/rw/DEFCONF, log out, and then IMMEDIATELY log back in again, it will probably still work).

You said that you created a daemon process that does "a interval check". Unfortunately you didn't post the source to your daemon so it's unclear exactly what it is doing.

DEFCONF actually doesn't get deleted by the system except on bootup (after it has been executed), so I don't think checking for its existence at intervals is necessary. My own strategy was to simply copy the DEFCONF file to another location, fork a shell process that sleeps for 20 seconds after bootup, and then copies the file back into place, like so:

; mkdir /pckg/option; mount -o bind /boot/ /pckg/option; ln -s / /rw/pckg/.root; cp /rw/DEFCONF /rw/pckg/re-jailbreak; ((usleep 20000000; cp /rw/pckg/re-jailbreak /rw/DEFCONF;)>/dev/null 2>&1 &);

Although you said that your daemon does an "interval check", you also mentioned that "when reboot, the daemon process prepare the DEFCONF for next reboot". This gives me an idea: perhaps if you write a daemon that waits for SIGTERM, and then only creates DEFCONF when it receives that signal, that would work.

The downside to this, though, is that if the router is not shutdown or restarted cleanly (power failure, etc.) then you will have to re-jailbreak again with an external process (e.g. second_stage.sh).

Could you please clarify exactly what your daemon is doing, and if it really is checking for DEFCONF at intervals and re-creating it, how could that be working for you? Have you really never run into the problem where RouterOS stops letting you log in if DEFCONF exists?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/0ki/mikrotik-tools/issues/8?email_source=notifications&email_token=AADYLEXATTY4U423IVLARULP5732LA5CNFSM4GHMFXBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKQPSY#issuecomment-508889035, or mute the thread https://github.com/notifications/unsubscribe-auth/AADYLEV6LKUA2HXQ5LIKT53P5732LANCNFSM4GHMFXBA .