Jump to content

AlfAlfa

Active Members
  • Posts

    70
  • Joined

  • Last visited

Recent Profile Visitors

1,541 profile views

AlfAlfa's Achievements

Newbie

Newbie (1/14)

  1. Send it over SSL wrapped email, and / or send a password reset link rather than just the password. (although someone who receives either could still use both reset types to gain access, so make the password reset step mandatory and they should also be required to enter some information that only they would know!) This way even if someone that shouldn't gets a hold of the password reset link or temporary password, they still would have to know a secret piece of information that doesn't get sent and that they won't be able to figure out or guess.
  2. You can just secure it with a WPA passphrase, rather than just having the network open. I do this with my PC, perhaps check my signature for the link to "Hosting you're own access point to share from one interface to another". Just adapt it for the pineapple, pretty similar it is. Aside from that, you just made me think of a really cool idea and I'm going to see how quickly I can create it! Another way I just thought of
  3. Just as an update, I had to get caught up in my other work, but I finally got uploadwpa2 into a state that it has been much improved and is a worthy update! Also something looks different about this module, dependency? The main difference is adding SSL support, but also switching from hard coded specialized functions which would have to be coded for each site and re-done if the site changed, to a json config file with the default config stored at ~/.uploadwpa2/sites.cfg It's a pretty simple format, and should be able to be configured for most sites except that require a logged in session or captcha. (maybe future features) So with the standard openwrt sdk now I'm fairly sure I got the packaging right this time, so check the package out or it can be just built from source again. additional dependencies: +libopenssl +libcrypto makefile has been updated. "I cant put enough emphasis on this, this is not an official package provided from the hak5 team, and there for is NOT supported by them. Until if and or when they add it into their official repos, and you download it from their official repos, this is all installed at YOUR OWN RISK. so using this provided ipk, do not go to the hak5 team for support for which are not officially provided by them. i also hold no responsibility for any damage or for your usage that may occur, i can provide the sources and installable ipk, and can give you my word that their is no malicious code added to this ipk, it is clean and has no infection. it is your choice and responsibility if you want to use them or not." You've been warned, now here is the goods :) --------------------------------------------------------------------------------------------------------------- IPK: http://www.filedropper.com/uploadwpa21ar71xx http://www.speedyshare.com/jwNNd/uploadwpa2-1-ar71xx.ipk Source: https://github.com/Alf-Alfa/uploadwpa EDIT: I've just realized I completely overlooked the javascript and php side of things, I'll have to flesh it out with support for the newer features. Like being able to give it more than 10 hashes at a time (you just configure how many hashes it accepts per post) and it sends out as many post requests as necessary to complete the job. (example of one new feature)
  4. Well actually, 'wlan0mon IEEE 802.11bgn Mode:Managed' doesn't look right. It should be Mode: Monitor no? When in that state try: 'iwconfig wlan0mon mode monitor' Then iwconfig again, and see if it's in monitor, or if it is and it changes back after a short while, then something is manipulating it still. As for getting stuck at the M2 message, I forgot whether it was -N (no nacks) or -n (always target ap nacks) that helped for getting passed that so try either one of those separately and see if it helps. Your device has to stay in monitor mode though or it's going to screw up. Also you should make sure you're using the latest reaver, and latest pixiewps for best results: https://github.com/t6x/reaver-wps-fork-t6x&& https://github.com/wiire/pixiewps Note: you'll have to build them manually if your package manager isn't holding an updated package, which is likely the case.
  5. I know sftp is kind of similar to scp but not exactly so what about scp?, did you try scp when you said 'webinterface or sftp etc'? I wonder if that will work: scp root@172.42.16.1:/root/caps/largecap.pcap ~/caps/largecap.pcap Excuse my post if you've already tried it, but you weren't clear on that. Maybe when downloading it uses up all or too much memory and that causes something vital to crash creating the issue you find... That's just a guess though because it's hard to see what's going on from your log files (as it looks almost like it was unplugged and re-plugged). Which is the first line that the transfer stops '[ 459.450000] usb 1-1.2: USB disconnect, device number 6' that one?
  6. Yes that's true, it should upgrade to HTTPS which it does for me. You're also right there isn't a 'disable HSTS setting' but a trick to get it to bypass HSTS (at least in firefox): "According to several forums, you can disable HSTS by introducing a new configuration variable. First, go to the Firefox configuration page (about:config), right-click, choose "New Integer", then provide the name "test.currentTimeOffsetSeconds" (no quotes) with a value of 11491200. This should bypass HSTS, although you may also need to clear the Cache and Active Logins in the Clear Recent History dialog (Ctrl-Shift-Del). This apparently works because of a function called GetPreloadListEntry that checks to see if the current time is less than the next list expiration time; since the time is effectively calculated to be later than the expiration time, no check is performed. This effectively disables HSTS checks." If you're on the box you can disable it is the point, but yes I agree it shouldn't be able to be disabled just through a MITM. Though setting that variable could be a neat trick to allow the old sslstrip to work again on a compromised box, until they change the code where that doesn't work anymore that is.
  7. Well then it's working then! That is a security feature called HSTS built into the browser. Once you go to the TLS/SSL version you can't go to the unsecured version anymore! That's what I think your issue is anyway, see this for a possibly working bypass: https://forums.hak5.org/index.php?/topic/37642-hsts-bypass-and-ssl-stripping/?hl=hstsOr use a custom browser, or one that lets you disable the feature.
  8. It doesn't for you? In my example above it did, I only did that to show that only that one byte out of the 4 bytes actually are changed. Typing two bytes would change the first 2 bytes of the four byte (32 bit) instruction, typing 3 changes the first 3 bytes, and typing 4 changes all four bytes of the one instruction. I think it'll do that no matter how many bytes you type it'll overwrite starting from the address you're at with however many bytes you typed after wx. If you look closely it goes from 10 40 00 26 to 14 40 00 26 -> 10 40 00 26 -> 14 40 00 26 All instructions for this architecture are 32-bit (4 bytes) in length, so it only really make sense to edit multiples of 4 bytes at a time unless the last instruction in the sequence of instructions you're modifying is just the first byte or just the first two or just the first three. Like in this case, the first instruction to be modified is also the last and only the first byte needs to be changed. EDIT: As for the hex editor method of patching, yes it isn't disassembling it's just showing the raw bytes of the file. The addresses also aren't different they are just based from 0 rather than 0x400000. In this image here you can see the ELF magic number header at offset 0 in the file, but at virtual address 0x400000 in radare2: And at offset 0x1fcc in the hex editor is virtual address 0x401fcc in radare2: (it's hard to see where the cursor is, but on the line with offset 0x1fb8 the cursor is grey before an 0x14 byte and the next line offset 0x1fd4 can be seen as 0x401fd4 immediately following the two lines highlighted in radare2) When looking at a file everything starts from 0 since that makes sense for files, the hex editor doesn't know it's a binary file or what kind of file it is at all it's just showing what the file is made of. In radare2 it knows it's a binary file so it also knows what the image base is (usually 0x400000) and uses that as the where to base everything from, since if you were looking at the memory of the application while it was running that is what addresses you would use and be looking at! The image base can be configured to be something else besides 0x400000, or it can even be randomized. (something like ASLR [address space layout randomization]) Most of the time though it is the default of 0x400000. That should clear it up... The hashes may not have to do with the admin console, but you said some places or files on the filesystem weren't accessible from root, maybe the tw user does have access to them, and that might be what they're using to store the admin control panel password which makes it inaccessible to the 'root' user. It could be possible that root isn't actually root, and tw is actually root or at least higher privileged than the 'root' user. If you 'ls -lah' what kind of files are owned by 'tw' and which are owned by 'root'
  9. WOOT WO0T! Awesome! So you've got it going! I'll just get the standard OpenWrt SDK then, the issue lies somewhere in the sdk i've downloaded which is more specific to the mk5. At least now I can see that it works! (I've removed that wrong ipk so there'll be no confusion as you've asked) Version 2.0 is almost complete, it also links to libopenssl and libcrypto and I've gotten it to compile even with my broken sdk, (except openssl didn't have the version it was requesting anymore and had to source it from somewhere else (1.0.1e)) Perhaps the standard OpenWrt sdk will have a newer version anyway (like 1.0.2)!
  10. Thank you again, I really do appreciate you trying to help me! I think the problem is I shouldn't of used that outside of the httpclient that's the only place I used it outside of it. replace line 43 in uploadwpa.cpp: if(!file) { http->Log("ERROR Cannot open file"); return false; }With:if(!file) { std::cout << "ERROR Cannot open file"; return false; }And if you have a version of HTTPClient.hpp that doesn't have these headers add them to the top as well: #include <stdio.h> #include <cstdlib> When I was compiling I had to add those, as the reduced version of the standard library doesn't automatically include them with iostream like the normal desktop verison does...You still didn't say what you're using though for your compiling, is it that much of a secret? lol
  11. Thanks for checking it out, as for the Tetra not being a mips I guess I read that wrong he said a newer RISC architecture but that didn't mean it's not mips just a newer better mips arch... As for it failing to extract the control file, I think there's something wrong with the way it's packaging it since the file is actually in there if I do this I can extract it manually: Alf@UNKNOWN:~/Downloads/uploadwpa-ipk$ tar xzvf uploadwpa_1_ar71xx.ipk ./debian-binary ./data.tar.gz ./control.tar.gz Alf@UNKNOWN:~/Downloads/uploadwpa-ipk$ tar xzvf control.tar.gz ./ ./control Alf@UNKNOWN:~/Downloads/uploadwpa-ipk$ tar xzvf data.tar.gz ./ ./bin/ ./bin/uploadwpa Alf@UNKNOWN:~/Downloads/uploadwpa-ipk$ ls bin/ uploadwpa Alf@UNKNOWN:~/Downloads/uploadwpa-ipk$ The control file itself contains: Package: uploadwpa Version: 1 Depends: libc, libstdcpp Provides: Source: package/uploadwpa Section: utils Status: unknown ok not-installed Essential: no Priority: optional Maintainer: OpenWrt Developers Team <openwrt-devel@openwrt.org> Architecture: ar71xx Installed-Size: 8198 Description: Uploads a WPA handshake to various online crackers! And the binary itself is mips so it wont execute on my x86_64 (didn't even try, just looked at it with readelf) I think I see the problem, when I open the individual control.tar.gz and data.tar.gz with a visual extractor I see: and inside the . folder is the control file! Unless that's how it's supposed to be, then that appears to be the problem. What could be wrong with my configuration that it creates that extra "." (dot) folder and that's why it isn't finding it. Downloaded another ipk for something else extracted it and it has the same thing, so that .(dot) folder actually does appear to be normal so that's not the problem! Looking more closely at the information you gave me though I think I see the actual problem. I'm using the older MK5 toolchain aren't I, and that isn't going to work for the nano and Tetra is it!? AR71XX is not AR93XX!! Or is it? Because it says when I enter the menuconfig with "make menuconfig" and select the first option 'Target System' I get: ───────────────────────── Target System ───────────────────────────┐ │ Use the arrow keys to navigate this window or press the hotkey of │ │ the item you wish to select followed by the <SPACE BAR>. Press │ │ <?> for additional information about this option. │ │ ┌───────────────────^(-)─────────────────────────────────────────┐ │ │ │ ( ) ARM Ltd. Realview board (qemu) │ │ │ │ ( ) Atheros AR231x/AR5312 │ │ │ │ (X) Atheros AR7xxx/AR9xxx │ │ │ │ ( ) Atmel AT91 │ │ │ │ ( ) Atmel AVR32 │ │ │ │ ( ) Broadcom BCM2708/BCM2835 I do have that option selected as well. Should a ar93xx*.ipk be generated or do the packages called ar71xx*.ipk fit under the same umbrella and are combined supported for both? So I'm confused, will the MK5 toolchain work, or do I need the newer one! You said you've got the environment set up, I bet you're not using the MK5 toolchain! I'll keep it in case I want to make my work backwards compatible for it, but I really should have the newer toolchain! I don't really need the firmware unless that's required since I'm not intending on extending the firmware or making anything 'baked into' the firmware, but just a way to produce a binary with a proper magic number. When looking at a valid binary what does the magic number look like? Is it different than: Magic: 7f 45 4c 46 01 02 01 00 01 00 00 00 00 00 00 00 ? CONFIG_TARGET_ar71xx: │ │ │ │ Build firmware images for Atheros AR7xxx/AR9xxx based boards. │ │ │ │ │ │ Symbol: TARGET_ar71xx [=y] │ │ Prompt: Atheros AR7xxx/AR9xxx │ │ Defined at tmp/.config-target.in:59 │ │ Depends on: <choice> │ │ Location: │ │ -> Target System (<choice> [=y]) │ │ Selects: HAS_SUBTARGETS [=y] && mips [=y]
  12. I was actually using just any old hex editor (in my case 'Bless') to do the patching, however yes you can actually use radare2 for that as well. Here's an example of using it to do that branch instruction patch. The first byte from 0x10 to 0x14 is what flips a beqz to a bnez For moving to addresses with 's' you have to add the 0x in front for hexadecimal, but when patching with wx [sequence of bytes] you don't put the 0x in front is what I've figured out... You also need to re-open the file as read-write as it opens it as read only at first, type "oo+" to do that. Alf@UNKNOWN:~/Downloads/PenTest$ cp webproc webproc-mypatch1 Alf@UNKNOWN:~/Downloads/PenTest$ radare2 -e -b 32 -a mips webproc-mypatch1 Warning: read (strtab) at 0x20 Warning: Cannot initialize strings table [0x00401b70]> oo+ File webproc-mypatch1 reopened in read-write mode [0x00401b70]> s 0x401fcc [0x00401fcc]> pd 1 ,=< 0x00401fcc 10400026 beqz v0, 0x00402068 [0x00401fcc]> wx 14400026 [0x00401fcc]> pd 1 ,=< 0x00401fcc 14400026 bnez v0, 0x00402068 [0x00401fcc]> wx 10 [0x00401fcc]> pd 1 ,=< 0x00401fcc 10400026 beqz v0, 0x00402068 [0x00401fcc]> wx 14 [0x00401fcc]> pd 1 ,=< 0x00401fcc 14400026 bnez v0, 0x00402068 [0x00401fcc]> exit As for assembling to actually know what the bytes are to write using 'wx' with the above method you can use rasm2 like this... I think it's important to differentiate between radare2 and rasm2 though, rasm2 assembles and radare2 disassembles. Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips "addiu v0, zero, zero" 24020000 Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips "jr ra" 03e00008 The first one 'addiu v0, zero, zero' is really the same as 'li v0, 0' This is because radare2 and most disassemblers use a pseudo syntax (as described here: http://www.howardhuang.us/teaching/cs232/03-More-MIPS-instructions.pdf)for cleaner looking code, but it really is the same as what the actual code is. If you instead put bytes into rasm2 instead of an instruction in quotes it'll do the reverse: (so I guess technically it does disassemble too, but a byte sequence rather than an entire binary file) Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -d 24020000 li v0, 0 Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -d 03e00008 jr ra Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -d 2402000003e00008 li v0, 0 jr ra I did however have trouble getting rasm2 to assemble any branch instructions with the instruction in quotes form: Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -o 0x401fcc "beq v0, zero, 0x402068" Cannot assemble 'beq v0, zero, 0x402068' at line 3 invalid Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -o 0x401fcc "bne v0, zero, 0x402068" Cannot assemble 'bne v0, zero, 0x402068' at line 3 invalid Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -o 0x401fcc "bne v0, zero, 0x26" Cannot assemble 'bne v0, zero, 0x26' at line 3 invalid Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -o 0x401fcc "bne v0, zero, +0x26" Cannot assemble 'bne v0, zero, +0x26' at line 3 invalid Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -o 0x401fcc "bne v0, zero, 26" Cannot assemble 'bne v0, zero, 26' at line 3 invalid Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -o 0x401fcc "bne v0, zero, 402068" Cannot assemble 'bne v0, zero, 402068' at line 3 invalid Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -o 0x401fcc "bne v0, 0, 402068" Cannot assemble 'bne v0, 0, 402068' at line 3 invalid There should be and probably is a way to get them to assemble properly, I'm just not sure how it wants me to type it for it to like it. You can however like described above do it the other way, give it bytes and it'll show you what it will produce :) So I used an online mips assembler here to know what bytes I should use: http://alanhogan.com/asu/assembler.php You can enter some test code like this: and then you generate the assembled code at the bottom, then on the second similar page you copy the blue colored output into it, and select verbose/debug + submit and you can see what it would do As you can see from part of the verbose output: Loading 0x00400044 : 1440fff0 ; <input:52> bne $v0, $zero, VZeroIsNotZero #branch if v0 does not equal 0 NOT branching [bne], because 0 does equal 0 Loading 0x00400048 : 1040ffef ; <input:54> beq $v0, $zero, VZeroIsZero #branch if v0 is 0 Branching [beq], because 0 does equal 0 1440fff0 -> 14 40 ff f0 1040ffef -> 10 40 ff ef The difference in the first two bytes is only the first one, from 0x14 (bnez) to 0x10 (beqz) The second byte I believe is the register, so if v0 was v1 or a2 or whatever that byte would be different. The last two bytes are the relative offset where the branch is going to actually jump to! So knowing that we can assemble our new branch instruction: Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -o 0x401fcc -d 10400026 beqz v0, 0x00402068 Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -o 0x401fcc -d 14400026 bnez v0, 0x00402068 Notice I add the -o parameter with the address the branch is being taken from, this is important at showing the right result, as like I said above branching is relative so based on the address you branch from + the offset is where it will go to. So for example if you didn't provide the address with the offset, it'll be the same as using offset 0: Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -d 14400026 bnez v0, 0x0000009c Alf@UNKNOWN:~/Downloads/PenTest$ rasm2 -e -b 32 -a mips -o 0 -d 14400026 bnez v0, 0x0000009c It'll still be the right code at the proper location that you place it (since branching is relative to that location), but using the offset here will show you that it's going to be correct! There we are, that should do it for now. I'm going to see if any of my old routers can be OpenWrt'd or at least if there's a telnet available or way to access the filesystem like yours so I could experiment with my own router as well, though last time I checked for OpenWrt support the site said it was possible but limited space and memory made it difficult, I wonder if there's been any progress made! As for the hashes, ah I see you used johnny to help you with them! So is it the right place or not? So what kind of hash is it? Just curious about that. ~Alf
  13. Would the gateway be 172.16.42.1 or 172.16.42.0 though? You can also set the DNS server to the same as the proper gateway address and it'll grab the DNS from the router/gateway instead of entering it manually. Are you sure foxtrot? Maybe I'm confusing regular router manual configuration with configuration for pineapples. On windows 7 if I don't put the gateway for a manual config with my router it doesn't work. That has probably changed in newer versions of windows and it does a better job of figuring it out automatically? However there has been cases where I had two interfaces up and had to not set the gateway in the second interface and only in the first. Also had to change the metric of the second interface to be higher than the first interface. (since I wanted it to get the internet access from the first interface, but still have the second connected at the same time) So just to be clear if you have two interfaces connected simultaneously in windows, set the one you want it to grab internet access to with a lower metric value than the one you just want connected but not to use for internet access. (the metric value is somewhere in the advanced settings)
  14. Well I've done it, at least for the nano I believe so: Does this look good? (Yes certainly, you can take a look and see if I did it correctly and test it for me, compiling it yourself, then let me know how I can do the same for the Tetra!) Look I don't want you to have to do everything for me, see I'm putting the effort in here! I should add: Thank you ahead of time. Alf@UNKNOWN:~/pineapple-builder/MK5/package/uploadwpa/package/bin$ readelf -a -d uploadwpa ELF Header: Magic: 7f 45 4c 46 01 02 01 00 01 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 1 Type: EXEC (Executable file) Machine: MIPS R3000 Version: 0x1 Entry point address: 0x401770 Start of program headers: 52 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x70001005, noreorder, cpic, o32, mips32r2 Since the MK5 and nano have a similar mips architecture is that correct? The Tetra on the other hand is different... Where can I download the firmware and cross compiler toolkit for it? See now this wasn't so hard was it, my github has been updated but the ipk isn't there just the updated source with the new makefiles and instructions on what I did to compile it. I did successfully generate an ipk though and extracted it and checked the binary to confirm it is in fact compiled for mips! As DataHead posted It previously when he's done this, I have to post this here too: I cant put enough emphasis on this, this is not an official package provided from the hak5 team, and there for is NOT supported by them. Until if and or when they add them into their official repos, and you download it from their official repos, this is all installed at YOUR OWN RISK. so using this provided ipk, do not go to the hak5 team for support for which are not officially provided by them. i also hold no responsibility for any damage or for your usage that may occur, i can provide the sources and installable ipk, and can give you my word that their is no malicious code added to these ipk, they are clean and no infection. it is your choice and responsibility if you want to use them or not. You've been warned, now here is the goods :) ------------------------------------------------------------ the main github has been updated to reflect successful compilation in a openwrt environment, if you would like to compile it yourself -> https://github.com/Alf-Alfa/uploadwpa [iPK link will be placed here shortly] Once copied to to your MK5 or nano: opkg install uploadwpa-1-ar71xx.ipk Then if nano you can also copy the 'UploadWPA' to /pineapple/modules for the GUI Otherwise you must use it from the command line once you have a terminal to your pineapple! Tetra version coming soon, as soon as I get the proper environment setup to cross compile for RISC.
  15. Well that just means I still haven't made it to pineapple module status yet ;)! I really thought you were going to help get my code compiled for the pineapple archs, but I guess you aren't proficient in native code cross compiling or just didn't want to accept a payment for just compiling someone else's module so you re-built it entirely yourself so you felt more like you earned it. That's understandable, however I'm going to do it bigger and better and enough work that you won't want to rebuild it entirely again this time! :) I'll let you have the capturing handshakes module though how about that! I'm also working on a completely different idea for a module that I don't want to let on to yet. I'll have to figure out how to cross compile though myself it seems... I'm just not sure if I need to link to libstdcpp or uclibcxx and which sdk to use is it Kamikaze or White Russian? Or a more pineapple specific sdk for cross compilation? this program uses strings and iostreams which are a feature of the C++ standard template library (STL). However, because memory is so critical in an embedded application like OpenWrt, the standard template library is not available by default. What needs to be done to fix the problem depends on which version of OpenWrt you are running. If you are running Kamikaze, the problem is much easier to fix than if you are running White Russian. If you are running Kamikaze, you only need to install the libstdcpp library. If you are running White Russian, as I am, you must install the uclibcxx library, as well as make certain changes to the Makefiles to use this library, which is a special implementation of the standard library for embedded devices I'll figure it out, I'm confident of that :) EDIT: Found this great post here by Darren https://forums.hak5.org/index.php?/topic/36422-cross-compile-c-code-to-mips/?hl=%2Bcross+%2BcompileThe thread starter was wanting to cross compile for the turtle, but this should get me set up so I can cross compile for the pineapple as well and there is a pineapple specific guide (though for the MK5) All I should need to do though is use the RISC and MIPS arch of the newer pineapples and it'll help me out to get there! Thanks Darren for that post, this should keep me busy for a while. Turns out it's libstdcpp selected Y to that on the configuration and I'm now building the MK5 firmware and toolkit with it: Almost there!
×
×
  • Create New...