digininja

More curious, I've just removed everything from that directory and then restarted apache but the phpinfo() still shows the same list of additional files.

Something I've just noticed, in the phpinfo() I have these entries: Loaded Configuration File /etc/php.ini Scan this dir for additional .ini files /etc/php.d Additional .ini files parsed /etc/php.d/20-bz2.ini, /etc/php.d/20-calendar.ini, /etc/php.d/20-ctype.ini, /etc/php.d/20-curl.ini, /etc/php.d/20-exif.ini, /etc/php.d/20-fileinfo.ini, /etc/php.d/20-ftp.ini, /etc/php.d/20-gettext.ini, /etc/php.d/20-iconv.ini, /etc/php.d/20-json.ini, /etc/php.d/20-phar.ini, /etc/php.d/20-sockets.ini, /etc/php.d/20-tokenizer.ini Yet my /etc/php.d directory has more files than that in it, including 30-mysqli.ini. I've tried copying that to 1-mysqli.ini just in case it was having problems with one of the 20's and so stopping loading the later ones but that hasn't helped.

I'm trying to help someone debug why they they can't get DVWA working on a Fedora 27 box so I built my own to test it out. I've installed MySQL from the official MySQL repo (i.e. no using the default MariaDB) and got standard Apache and PHP installed. PHP is running as php-fpm. [root@localhost php-fpm.d]# php-fpm -m |grep mysql mysqli mysqlnd pdo_mysql [root@localhost php-fpm.d]# php -m |grep mysql mysqli mysqlnd pdo_mysql The mysqli modules are installed but when I try to use mysqli_connect I get an error saying the function doesn't exist. Checking phpinfo() and that agrees, there is no mention of the mysql extensions. [root@localhost php-fpm.d]# cat /etc/php.d/30-mysqli.ini ; Enable mysqli extension module extension=mysqli.so [root@localhost php-fpm.d]# locate mysqli.so /usr/lib64/php/modules/mysqli.so /usr/lib64/php-zts/modules/mysqli.so The mysql extension files are on the box and are referenced in the php config so I'm assuming that should enable them, I've not used fpm before. The php-fpm ini file test says it is OK [root@localhost php-fpm.d]# php-fpm -t [28-Feb-2018 14:29:21.074218] NOTICE: pid 30341, fpm_conf_init_main(), line 1717: configuration file /etc/php-fpm.conf test is successful But I still get this error in the log file: [28-Feb-2018 14:30:42 UTC] PHP Fatal error: Uncaught Error: Call to undefined function mysqli_connect() in /var/www/html/dvwa/includes/dvwaPage.inc.php:467 Can any Fedora experts out there help? I'm assuming that I've not enabled the module correctly but not sure what I need to do to enable it. And to preempt certain answers, this is a very specific config that I'm trying to debug, I don't need advice on getting this working using different distros or application stacks.

Yes, that sounds right. I am wondering though whether you should actually combine the two so you actually have a string that is between 12 and 16 characters and do the maths on that but I don't think that would be right.

I wasn't great at maths stats at college but isn't it: Number of possible characters in first position = 26+26+10 = 62 For a one character password there would be 62 different possbilities For two chars: 62 * 62 = 62 ^ 2 Three chars: 62 ^ 3 ... Six chars: 62 ^ 6 Seven chars: 62 ^ 7 Eight chars: 62 ^ 8 For 6, 7 or 8 chars: (62 ^ 6) + (62 ^ 6) + (62 ^ 8) = 221918520426688 = 221,918,520,426,688 So yes, I'd agree that you got it right.

That isn't an answer to the question. Are you worried about getting malware on your machine, being watched by your ISP, being attacked back if you attack someone else, getting caught doing something illegal? An important skill in the security industry is being able to define threats and risks. Who or what is a threat to you, what is the risk from the threat? During the period when the guys from Anonymous were getting arrested, we got a lot of people asking how they could hide from the NSA as they saw them as a threat. The reality for the vast majority of them was that the NSA is absolutely no risk to them as all they were doing was the odd bit of piracy and surfing porn that they didn't want their parents to know about. Those two activities warrant completely different defenses to defending against the NSA. If you want to learn and stay "safe", stay local. Build yourself a lab with vulnerable apps like DVWA, Metasploitable and other similar machines. You can also build your own machines, get old Linux distros and install known vulnerable apps. You'll learn a lot more doing all this than just randomly throwing tools against stuff online. You don't need to do trawling dodgy sites, all the info you need is available through legitimate sources. Use the same commonsense that you would use doing anything online and you'll be fine, browse shady websites and download random stuff from untrusted sources then you'll get screwed.

What are you concerned about? What are you trying to guard against?

What type of safety? Who are you planning to run your tools against?

So you aren't really asking about staying safe online you are asking about how to use tools without getting caught. Two very different things.

You asked about staying secure which is what Tails will help you with, what is it in Kali that you want?

Just to be pedantic, a live OS wouldn't stop stuff being installed but would stop persistence over reboots.

Search for the dc4420 group, they meet once a month in London.

This sounds very much like a homework question so let's start with you, where do you think they can be used?

Probably your best option is to use Tails, it will do all the setup for you. Their site also has documentation on getting you started. Just remember that no solution is perfect so never assume what you are doing is completely private, it all depends on the resources of your adversary.

Me thinks you aren't taking this super leet hacking group seriously.

We don't allow or condone illegal activities on this site, even if you believe you are doing them for the good of society or have the moral high ground. What are the plans for this group of yours?

Try talking to them, I'm pretty sure they both have people on staff that can help you. It it fairly specialised so maybe not the type of thing that ends up on the web site.

Assuming you are based in the US, look at Black Hills Infosec and Inguardians , both have people on staff who have done work in the area.

Check for weak local user passwords and weak domain ones that are cached. Definitely look at the man in the middle for app updates, it can be an easy way to get code running on the box as admin.

Does the machine boot from fully off without requiring a password? If so, look for open ports, see what services it is running that are exposed to see if any of those can be exploited. See what the box calls out to when booted, do any of those include credentials? Can any of those be intercepted? Maybe an app checks for updates that you can intercept and reply with a custom one. I've not kept up on them, but do the FireWire attacks still work? There was a DMA issue where you could read memory. There was a second interface type that also allowed it, can't remember which it was.

That's not a pentest. First, define your risks, for example, stolen when turned on, turned off, standby, sleep. Then take each of those scenarios and see what state the drive is in and see if you can access it locally or remotely. If it is on and there is VNC with no password then FDE does nothing, if it is off and the password for the encryption I'd strong then you are likely to be OK. You need to think of all the different things between these two.

Define what you mean by pentest it.

Very simple, you don't. It is illegal to attack systems you don't own or have permission to attack and despite this being "your work" address, you would be attacking Google who don't take kindly to that type of thing.

Lets look at your assumptions.... If you are worried about a rogue sh or bash process then you have to be assuming that someone has managed to get something onto your machine in the first place, how they did that, I don't know. You are also then assuming that, once the rogue app is on there, that it is set to run in some way, again, this is based on your assumption that something malicious is running that is creating the sh or bash processes. So, making those two assumptions, I would install a ruby script rather than something that requires bash or sh to run, I would then have that start using the ruby interpreter which would create a ruby process, not a bash or sh one. That would not get killed by your script as it isn't looking for ruby And I did test the script, once my script is running, there are no additional bash or sh processes created.

No I wouldn't, there are loads of ways to get shell on a machine that don't involve either bash or sh. The following ruby script will execute the sleep command which will sleep for 60 seconds, run this and see if your killall kills it. #!/usr/bin/env ruby %x{sleep 60} Then simply update the script to listen on a network port for commands coming in and then have it execute them instead of the sleep. One shell, no bash or sh. And, as I said before, if I wanted a bash like shell, I'd just drop tcsh, zsh or csh on there and use one of those which you aren't killing.